First impressions

Hi,

Got a chance to look at this today, and, erm, well, if compatibility is the goal then it's wide of the mark I think.
Our application is ready to ship, so the number of issues under 4.0.7 is very low, and certainly nothing too serious.

Thought I'd try with the new beta since you've stated that it should be compatible, and am interested in seeing the performance improvements, especially under older IEs...

Under 4.1.0 am having lots of trouble with my custom tree (additional data being attached to the root node is getting lost, breaking my configuration and load process completely), and grids appear to not be displaying all data (can see two records coming back, but only one is in the grid, so I assume store).
No real progress with either of these yet, but will try and find out what is going on... looking at the tree first.

Some observations so far; will add more as I spot them.

AbstractComponent.getState used to return an empty object if there was no state, now it returns null.
This means classes overriding the behaviour need to OR the result from calling parent with {} to ensure they can use the object.

Can't slice my theme; get a whole load of errors.
Assuming it needs a new version of the SDK? If so where is it please (Windows please, my MBP is no longer my work machine)?

Changes to TreeStore.setRootNode appear to be causing my first problem with my tree... still investigating. Suspect it's my old mate NodeInterface, it really is the bane of my life that horrid thing!

Have removed nearly all the my "framework fixes" (Ext overrides basically), except fairly trivial ones that I have spotted have not been addressed (and are nothing to do with layout, drawing, components, elements etc), so have a fairly clean slate.

Subjectively, layout seems snappy, but of course since it's having trouble loading most of my data it's bound to be quick

There are lots of fixes in there for trees and grids. I personally haven't seen any problems with my grids and I usually try to stay away from trees (have never liked them so just my personal opinion ). So things should work but when there are this number of major reworks then it is kind of to be expected to have some hiccups. Best of luck to you and we would like to hear of any progress you make. Any tips would be looked at as we develop for a GA release.

The constructor returned by getPrototypeBody calls the parent Model class, which only allows data defined in the model's fields to persist. Suppose I could override decorate, since that "hacks in" the fields it needs...

This class really is so out of place with everything else in the framework though, it's just so inaccessible.
The only way to fix issues with it's methods is to, I suppose, override getPrototypeBody, call overridden, then apply your overridden methods to the object returned...

I usually try to stay away from trees (have never liked them so just my personal opinion ).

I did a little work with the Ext 3.3 tree... and I thought the code was scalable and relatively easy to work with. I compared it with the Dojo tree widget... Ext could easily handle 500+ child nodes, but Dojo would limit around this number as each node is a widget in a Dojo tree

There are lots of fixes in there for trees and grids. I personally haven't seen any problems with my grids and I usually try to stay away from trees (have never liked them so just my personal opinion ). So things should work but when there are this number of major reworks then it is kind of to be expected to have some hiccups. Best of luck to you and we would like to hear of any progress you make. Any tips would be looked at as we develop for a GA release.

Finally got my tree loading through a combination of updating my model (ensuring that defaultValue for fields is set to undefined rather than the empty string for objects that I add into the data), and hacking one line of the new code out of NodeInterface.

In appendChild, the loaded flag is being set when it shouldn't be (at least if I comment this out then everything works fine):

Code:

if(!node.isLeaf() && node.phantom) {
node.set('loaded', true);
}

Will try and track down why it thinks my nodes are phantoms next I suppose.

Calling load on an arbitrary node (i.e. refreshing children) appears to be broken; possibly something to do with clearOnLoad... looking into it.

Edit: Sorted.
When introducing an id property for your model, it's essential it is unique otherwise get some strange effects (I used a type/id combo, since auto number db ids can clash across tables).
I think to do with the clearing of removed nodes that has been introduced.