Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-1521 in a recent build.
  1. #1
    Sencha User
    Join Date
    Feb 2012
    Posts
    17
    Vote Rating
    0
    vokiel is on a distinguished road

      0  

    Default Beta3: TreeStore corruption with an AsyncTree implementation.

    Beta3: TreeStore corruption with an AsyncTree implementation.


    I pull all nodes of my tree asynchronously in a similar way as in http://www.sencha.com/examples-dev/#...lace:asynctree but with autoload enabled.

    Code:
        @Override
        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/showthre...erClick-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.

  2. #2
    Sencha User
    Join Date
    Feb 2012
    Posts
    17
    Vote Rating
    0
    vokiel is on a distinguished road

      0  

    Default


    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.

  3. #3
    Sencha User
    Join Date
    Feb 2012
    Posts
    17
    Vote Rating
    0
    vokiel is on a distinguished road

      0  

    Default


    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.

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


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

  7. #7
    Sencha User WesleyMoy's Avatar
    Join Date
    Oct 2009
    Location
    Redwood City, California
    Posts
    402
    Vote Rating
    2
    WesleyMoy is on a distinguished road

      0  

    Default


    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.

Thread Participants: 2

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi