-
TreePanel Issue
So when we upgraded from v4.8 to v5, our TreePanel completely disappeared and we cant figure out why.
There are no JS errors or anything amiss.
We verified that the JSON is returning properly by using fiddler.
We did find a odd bug in ext in that we build our JSON on the controller side and set Icon=Icon.Group or something like that.
Now the JSON that is generate is invalid and JSONLint wont validate it.
Code:
"iconCls": X.net.RM.getIcon("Group"),
Now when this occurs, we added a debugger to the Load event of the store and success is true and records.len=0
We comment out all the .Icon assignments in the controller and success is true and records.len is proper size.
However in both cases, the TreePanel is completely blank. And we have no errors.
I need some assistance on this one but it might require a offline screenshare. I dont have any standalone example to share
thanks
/Z
-
Can you check the Developer Tool Console in the browser to see if any JavaScript errors are being thrown? Any details you can provide that would help isolate the problem will be helpful.
-
No JS errors at all in the console.
I consider myself well versed in EXT and front end and this has me stumped.
You can my email. Can we do a webex and i can show you. i dont see any other way....
thanks
/Z
-
Hello @Z!
This is most likely due to a breaking change we documented during the v5 upgrade process.
The list of breaking changes is available in github and you can view it in this link: https://github.com/extnet/Ext.NET/is...reaking-change
We have actually delayed several breaking changes Sencha introduced throughout Ext JS 6.x (that were included in the Ext.NET 4 versions), and finally lifted them in the Ext.NET 5 release.
The two issues, in order, I am most suspicious might be causing your problem are the following:
1. #1605 - Stop forcing Ext.USE_NATIVE_JSON as false (use Ext JS default)
2. #1677 - Remove InitScriptMode.LinkedJS, merging it with InitScriptMode.Linked
In (1) above, as your problem seems to relate with the json processing to populate your tree, and per the json snippet you shared, really look like the issue. This happens because the previous versions, by default, used Ext.USE_NATIVE_JSON as false which means an Ext JS implementation of JSON.parse was used by default, instead of the browser implementation of the function.
Since Ext JS 6.6.0, shipped with Ext.NET 4.7.0, Sencha turned this setting as true by default and, by the potential of breaking things within the same major version, we chose to retain the default from other versions until we switched to a major version release. This issue might provide you important information on why this default has changed and why it may be interesting for you to comply to the change instead of reverting the setting to false: #1604 - Ext JS 6.6.0 reliance on native JSON breaks Ext.NET implementations.
Basically the difference between native or not native implementation is that the native one is true JSON format; the Ext JS implementation of the method is actually a javascript object instead, which is evaluated/parsed (eval()) at some point. And that's what makes it so likely the "JSON" snippet you pasted (which is not JSON at all, that's a JS Object member definition) would no longer work with Ext NET 5.
To switch the default to false and ensure this is your issue, you should add javascript code between Ext JS scripts load and the page's client script. One way to achieve this is by calling this on your Page_Load() method:
Code:
X.ResourceManager.AddBeforeClientInitScript("Ext.USE_NATIVE_JSON = false;");
This will ensure the very first code run in the client init script, before any component used in the page is actually referenced, is the one switching the predefined setting.
Hope this helps you fix the mysterious issue. Please consider using the new default per the security concerns involved.
Ext.NET had some code that relied in the non-native implementation of JSON decoding, and all issues were reasonably feasible to be addressed -- sometimes calling eval() directly when strictly required.
-
So we downgraded from v5 to v4.8.3 and the problem still persists :)
we are going to rollback the entire MVC5 upgrade and try again from scratch.
thanks
/Z
-
Hello @Z!
It's been some time and you didn't post any news about the issue. Did you get it working when you rolled back the version? Perhaps you found out the matter? Or maybe came down to the same issue after rolling back and then forth towards latest Ext.NET?
We're looking forward to your follow-up!
You know, we may mark this thread as closed if you still post nothing in here after 7 business days from now; we won't lock up the thread, so it will still be available for further discussion for as long as needed.
