PDA

View Full Version : First impressions



westy
3 Jan 2012, 8:39 AM
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 ;)

More as I get it.

Cheers,
Westy

mitchellsimoens
3 Jan 2012, 8:45 AM
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.

westy
3 Jan 2012, 9:21 AM
Yeah, NodeInterface... grr

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... :(

westy
3 Jan 2012, 9:24 AM
Ahh, just saw your reply Mitchell, long time no "speak"... really must refresh more often :)

So, is there a plan with some timescales, i.e. when do I need to get my rants in by so can have a hope of them getting picked up, or at least answered?

LesJ
3 Jan 2012, 12:08 PM
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 /:)

mschwartz
3 Jan 2012, 1:07 PM
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.

Good things come from trees. Like oranges.
:D

westy
4 Jan 2012, 1:11 AM
Progress of a sort; needed to add my additional "fields" (which they are not really) to an explicit model behind the TreeStore rather than rely on the implicit one that gets created automagically...

NodeInterface is still biting me later in the process, but have a call to the server going now at least, just b0rks when it comes back ;)

westy
4 Jan 2012, 4:00 AM
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):


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


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


Edit: Ahhh, it's the idProperty stuff in the model I think... will try it.
Edit2: Yep, setting my idProperty gets my tree loading. Glad I read the "gotchas" post ;)

westy
4 Jan 2012, 5:43 AM
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.

westy
4 Jan 2012, 7:11 AM
I notice you don't use Ext.create anywhere anymore, but instead use new.
I'm guessing it's for the performance improvement.

So, should we no longer be using create for our own classes?
What impact does this have on the build process with JSBuilder?

mitchellsimoens
4 Jan 2012, 7:19 AM
I notice you don't use Ext.create anywhere anymore, but instead use new.
I'm guessing it's for the performance improvement.

So, should we no longer be using create for our own classes?
What impact does this have on the build process with JSBuilder?

Yes, we save some performance by using new internally. If the class is already loaded then there is really no need for using Ext.create.

westy
5 Jan 2012, 3:36 AM
Edit: Going to break out further posts into their own threads else some will never get spotted...

westy
5 Jan 2012, 8:14 AM
Just to add, this bug (http://www.sencha.com/forum/showthread.php?170779-Drag-amp-drop-or-resize-of-windows-rendered-in-container-is-wrong) has now bitten me, and not convinced by Evan's answer at this stage; renderTo is a config option for a component so you can't add it as a child of the component at that stage since it does not exist yet...