Results 1 to 6 of 6

Thread: Trees can have "unsynchronized" TreeStores ->NullPointers

Hybrid View

Previous Post Previous Post   Next Post Next Post
    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2430 in 3.0.3.
  1. #1
    Ext GWT Premium Member
    Join Date
    Oct 2007
    Posts
    44
    Vote Rating
    3
      0  

    Default 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:
    Code:
      protected void onUpdate(StoreUpdateEvent<M> event) {
        for (M item : event.getItems()) {
          TreeNode<M> node = findNode(item);
          if (node.model != item) {
            node.model = item;
          }
          refresh(item);
        }
      }
    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:
    Code:
    	protected void onUpdate(StoreUpdateEvent<M> event) {
    		for (M item : event.getItems()) {
    			TreeNode<M> node = findNode(item);
    			if(null == node)
    				register(item);
    		}
    		super.onUpdate(event);
    	}
    This causes the missing nodes first to be registered and then "updated".
    Last edited by acerberus; 3 Aug 2012 at 2:19 AM. Reason: typo

  2. #2
    Ext GWT Premium Member
    Join Date
    Oct 2007
    Posts
    44
    Vote Rating
    3
      0  

    Default

    Thoughts?

  3. #3
    Ext GWT Premium Member
    Join Date
    Oct 2007
    Posts
    44
    Vote Rating
    3
      0  

    Default

    and .. one more push.

  4. #4
    Ext GWT Premium Member
    Join Date
    Oct 2007
    Posts
    44
    Vote Rating
    3
      0  

    Default

    at least an acknowledgment of this thread would be nice. Otherwise I don't really see the point of writing up bug reports ..

  5. #5
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976
    Vote Rating
    132
      0  

    Default

    I pushed this thread to the internal tracking system so it can be looked at. Thanks for bringing it up.

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737
    Vote Rating
    93
      0  

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •