View Full Version : [FIXED] Beta3: TreeStore corruption with an AsyncTree implementation.

29 Feb 2012, 8:38 AM
I pull all nodes of my tree asynchronously in a similar way as in http://www.sencha.com/examples-dev/#ExamplePlace:asynctree but with autoload enabled.

public void load(final IsANode loadConfig,
final AsyncCallback<List<IsANode>> callback) {
// Load the roots
if (loadConfig == null) {
SomeRpcFacade.load(requestFactory, callback);
} else {
loadConfig.loadChildren(requestFactory, callback);

This works really well until you use a filter on the store. The filter seems to be corrupting the store once you clear the text field manually or if I use the trigger as in http://www.sencha.com/forum/showthread.php?183974-Beta3-StoreFilterField-doesn-t-clear-the-filter-when-the-built-in-TriggerClick-occurs.

I'm trying to debug this, so I realize as a far as a bug report goes, it's pretty weak for the moment, unless someone can relate.

29 Feb 2012, 8:45 AM
Ok I found the issue, didn't notice the little Error message in the gwt dev window:

"The given model is already in the TreeStore, and should not be assigned a new node".

Edit: There does seem to be some bug with this as the replaceChildren method gets a wrapped node from the store that has no children when it should.

Still investigating so I'll update later.

29 Feb 2012, 12:26 PM
Before I forget

Bug is: The TreeNodes in the TreeStore aren't updated when a filter is removed, so the old state of the tree seems to be what is rendered. So workaround is thrash the store, get the loader to refresh the tree.

Colin Alworth
1 Mar 2012, 12:35 PM
Thanks for this (and your other TreeStore post), I'm going to try to address each of the issues you've run into to make sure I understand them, or if they are usability ones, how we can make this easier to use.

For the asserts - we could make the error more noticable if you think it would help. We only want them to be asserts so that they don't run in production, as they are doing an otherwise unnecessary map lookup on every item that is added. This is meant to be a sanity check that the data makes sense, and that update shouldn't perhaps have been called instead.

For the other issue - do I understand correctly that this seems to boil down to just using replaceChildren with filters, and removing a filter? Store.removeFilters checks first that the filter was even present, then if filters are enabled. If it wasn't present, or filters were already disabled, there should be no need to apply the filters again. In your case, both should be true. TreeStore.applyFilters then checks again if filters are enabled, and if at least one filter is in the list, otherwise it just fires an event. Removing a filter (down to more than zero) then results in completely applying all filters again. On the other hand, removing filters down to zero means that items are not filtered at all any more. This seems to be the most likely case for your bug.

All TreeStore.TreeModel operations should check if a) the filters are enabled, and b) if there are any filters, in the same way as applyFilters does, and if both are false, it should return only the full set of children. We have a handful of unit tests covering these cases, but from your bug we seem to be missing at least one case, or perhaps your filter is changing in a way we don't support or didn't anticipate.

To help solve that one way or another, can you post a simple Entrypoint that demonstrates this issue, or at least a series of steps to reproduce this (like 1. add filter, 2. use replaceChildren/replaceSubTree to add items, some visible, some not?, 3. remove original filter). My very brief initial testing hasn't demonstrated the issue yet.

Colin Alworth
1 Mar 2012, 12:42 PM
Okay, I've managed to make it happen, and will update this thread when the fix is available.

In the meantime, it appears that clearing the children and adding the new ones should work around this.

Colin Alworth
14 Mar 2012, 7:11 AM
This has been fixed in SVN and will be available in the next release.

28 Mar 2012, 2:37 PM
This bug has been fixed in the Ext GWT 3.0 Release Candidate. Please upgrade your copy of Ext GWT and try your test case again. While we're confident that we've addressed this issue, please reply if you notice any continued problems after upgrading. Again, thanks for taking the time to report this bug.