Trees can have "unsynchronized" TreeStores ->NullPointers

Trees can have "unsynchronized" TreeStores ->NullPointers

Hi,

there is a bug in Tree(Panel)s caused by unsynchronized Stores. If a Tree is given a TreeStore it adds handlers to listen to store events. For example an added entry in the store causes the tree to register a new node. Certain events, however, can cause the store and tree to become unsynchronized. Examples are:

Filtering

Loading store data before giving the store to the tree

Probably more

If now an update on the store occurs, the tree's onUpdate method is called:

Here the tree assumes that a node corresponding to the updated StoreModel exists. However, due to the two not being completely synched, this may not be the case. In this case findNode(item) return null and the whole thing produces a NullPointerException:

Code:

Caused by: java.lang.NullPointerException
at com.sencha.gxt.widget.core.client.tree.Tree$TreeNode.access$1(Tree.java:345)
at com.sencha.gxt.widget.core.client.tree.Tree.onUpdate(Tree.java:1864)
at com.sencha.gxt.widget.core.client.tree.Tree$Handler.onUpdate(Tree.java:510)
at com.sencha.gxt.data.shared.event.StoreUpdateEvent.dispatch(StoreUpdateEvent.java:101)
at com.sencha.gxt.data.shared.event.StoreUpdateEvent.dispatch(StoreUpdateEvent.java:1)
at com.google.gwt.event.shared.GwtEvent.dispatch(GwtEvent.java:1)
at com.google.web.bindery.event.shared.EventBus.dispatchEvent(EventBus.java:40)
at com.google.web.bindery.event.shared.SimpleEventBus.doFire(SimpleEventBus.java:193)
at com.google.web.bindery.event.shared.SimpleEventBus.fireEvent(SimpleEventBus.java:88)
at com.google.gwt.event.shared.HandlerManager.fireEvent(HandlerManager.java:127)
... 40 more

A temporary bugfix is to override the onUpdate method with the following:

This has been fixed in SVN and nightly builds, and will be available in the next release.

We took a little different approach to fixing this, and tried to make it more than just the cases provided. Instead of doing a null check in the tree itself, the TreeStore is no longer firing events for nodes that are not visible, so that the Tree doesn't even need to think about them. This makes sense, since the TreeStore only exposes access to the nodes that are actually visible (i.e. not filtered out), so doing this should prevent issues like this. This was fixed for StoreAddEvents from addSubTree, StoreDataChangedEvents from replaceSubTree, and replaceChildren, and StoreUpdateEvents from update. A handful of other bugs were also demonstrated when building unit tests for this, mostly related to filtering and adding sub trees, these were fixed as well.