Tree: bug related to mayHaveChildren and pasteItem with Observable store

classic Classic list List threaded Threaded
10 messages Options
psg
Reply | Threaded
Open this post in threaded view
|

Tree: bug related to mayHaveChildren and pasteItem with Observable store

psg
I have posted a bug here: https://bugs.dojotoolkit.org/ticket/17465

But for your comments or to help you with your research, here are the details:
 My code is too big to post here and due to tight schedule i cannot spend the time right now to write a clean simple example. Apologies for this. Here is the description:
I have:

    1. Relational data items, where each item knows now how many children it has and the id of its parent.

    2. Observable Memory store with:

        2.a. "getChildren" method querying with {parentId: item.id}
        2.b. aspected "put" method supporting options.parent to set the parent id and increment the parent's number of children and optionally decrement the original parent's number of children.
        2.c aspect "remove" method to optionally decrement the original parent's number of children.

    3. ObjectStoreModel with "mayHaveChildren" method that returns true based on the exact number of children (no queries).

    4. Tree using the model from 3

After the initial load, the tree looks nice and shows expandoes only when necessary, but when you try to move an item programmaticaly (using "pasteItem" method) under another item that did not have any children, the moving item simply disappears. My guess is because the node was already created without the expando and the store.getChildren was not called, therefore no QueryResults were there to "observe".

To me the model should recognize the case and instruct the tree to re-create the _TreeNode appropriately.

One work-around is to change the "mayHaveChildren" to always return true. This works even if you expand the potential parent while it doesn't have any children (so that the expando disappears), because the store.getChildren get called followed by QueryResults.observe. But this solution makes the tree look unnatural...

Another work-around that I haven't tested yet is to detect the case and remove and re-add the parent.
UPDATE: The second work-around works as well, as long as you execute the model.newItem(item, parent) asynchronously after to let the tree completely remove the node after the store.remove(parentId) call.

Another minor inconvenience is the model's reliance on the original item being passed to the "pasteItem" method.
If you hold the entire object in the tree and want to edit it in form and update back the results to the tree, you have to remember to use lang.mixin(originalStoreItem, formData) (where formData = form.get("value"))
psg
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

psg
Still the second "more correct representationaly" solution doesn't cut it entirely as it doesn't work if the child you are moving contains children. The chidren of the moving child are not displayed.

The tree must support programmatically moving the nodes.

The only real option I can think of is recreate the entire tree...
psg
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

psg
The bug got rejected, but I still think it is a serious design limitation of the Tree. The mayHaveChildren  method may be a good way to improve efficiency during the initial load, but it shouldn't set in stone the future behavior of the tree. Either the tree and its model should be able to work out changes to a node's state or there should be a method to request the Tree to explicitly rebuild the ui of a particular node.

A good analogy is the windows explorer navigation tree, where a folder won't show the expando if it doesn't have a subfolder, but if a folder is created by other means while the navigation tree is open, the folder node will show the expando immediately.

I have a big set of items the large majority of which don't have sub-items. But any of them can be configured to have children while the tree is present. It doesn't look correct for all the items to show expandos unnecessarily. For now my second work around partially works for me and I have provided means for the users to re-build the tree entirely.

If anybody know of a better way to handle the situation, please let me know.


There is an enhancement request 11065 opened 3 years ago against dojo 1.4.2. It partially covers what i need.
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

shane
In reply to this post by psg
There was another workaround, I think maybe setting autoExpand to true worked around this issue, although it auto-expanded the node with newly added children.  If that’s not it let me know and I’ll look for other possibilities; I have code with that worked around the issue.  



On Sep 24, 2013, at 10:44 AM, psg <[hidden email]> wrote:

> I have posted a bug here:  https://bugs.dojotoolkit.org/ticket/17465
> <https://bugs.dojotoolkit.org/ticket/17465>  
>
> But for your comments or to help you with your research, here are the
> details:
> My code is too big to post here and due to tight schedule i cannot spend
> the time right now to write a clean simple example. Apologies for this. Here
> is the description:
> I have:
>
>    1. Relational data items, where each item knows now how many children it
> has and the id of its parent.
>
>    2. Observable Memory store with:
>
>        2.a. "getChildren" method querying with {parentId: item.id}
>        2.b. aspected "put" method supporting options.parent to set the
> parent id and increment the parent's number of children and optionally
> decrement the original parent's number of children.
>        2.c aspect "remove" method to optionally decrement the original
> parent's number of children.
>
>    3. ObjectStoreModel with "mayHaveChildren" method that returns true
> based on the exact number of children (no queries).
>
>    4. Tree using the model from 3
>
> After the initial load, the tree looks nice and shows expandoes only when
> necessary, but when you try to move an item programmaticaly (using
> "pasteItem" method) under another item that did not have any children, the
> moving item simply disappears. My guess is because the node was already
> created without the expando and the store.getChildren was not called,
> therefore no QueryResults were there to "observe".
>
> To me the model should recognize the case and instruct the tree to re-create
> the _TreeNode appropriately.
>
> One work-around is to change the "mayHaveChildren" to always return true.
> This works even if you expand the potential parent while it doesn't have any
> children (so that the expando disappears), because the store.getChildren get
> called followed by QueryResults.observe. But this solution makes the tree
> look unnatural...
>
> Another work-around that I haven't tested yet is to detect the case and
> remove and re-add the parent.
> *UPDATE*: The second work-around works as well, as long as you execute the
> model.newItem(item, parent) asynchronously after to let the tree completely
> remove the node after the store.remove(parentId) call.
>
> Another minor inconvenience is the model's reliance on the original item
> being passed to the "pasteItem" method.
> If you hold the entire object in the tree and want to edit it in form and
> update back the results to the tree, you have to remember to use
> lang.mixin(originalStoreItem, formData) (where formData = form.get("value"))
>
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Tree-bug-related-to-mayHaveChildren-and-pasteItem-with-Observable-store-tp3999377.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
>
> [hidden email]
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
psg
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

psg
Thank you for the suggestion.
I was thinking about this as well. I didn't use it, because my data is relatively big (~1300 items).
Initially I was loading all items without parents on the root level, but the performance was not good.

Then I switched to artificial nodes that group the items by their first character (A,B,C, etc.), so initially you only see the groups. This improved the performance dramatically. I am afraid by turning autoExpand on, I'll be back to bad performance.
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

shane
You could try turning on auto-expand after the initial tree has been loaded, so it’s only in effect for dynamically added nodes, if that works.   You still have an issue if you’re adding to collections with large numbers of children, but less so than starting out with the entire tree expanded.  I’m not sure that would work, but then again, I’m not even positive I’m recalling the correct workaround (although I’m pretty positive it was the workaround for this problem).

Yes, I could see creating an “Orphans” group that may have its children grouped by first character…



On Sep 25, 2013, at 8:49 AM, psg <[hidden email]> wrote:

> Thank you for the suggestion.
> I was thinking about this as well. I didn't use it, because my data is
> relatively big (~1300 items).
> Initially I was loading all items without parents on the root level, but the
> performance was not good.
>
> Then I switched to artificial nodes that group the items by their first
> character (A,B,C, etc.), so initially you only see the groups. This improved
> the performance dramatically. I am afraid by turning autoExpand on, I'll be
> back to bad performance.
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Tree-bug-related-to-mayHaveChildren-and-pasteItem-with-Observable-store-tp3999377p3999419.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
>
> [hidden email]
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

shane
Or use a subclass of TreeNode that doesn’t propagate expand() to the super class if the tree is loading.



On Sep 25, 2013, at 9:00 AM, Shane Green <[hidden email]> wrote:

> You could try turning on auto-expand after the initial tree has been loaded, so it’s only in effect for dynamically added nodes, if that works.   You still have an issue if you’re adding to collections with large numbers of children, but less so than starting out with the entire tree expanded.  I’m not sure that would work, but then again, I’m not even positive I’m recalling the correct workaround (although I’m pretty positive it was the workaround for this problem).
>
> Yes, I could see creating an “Orphans” group that may have its children grouped by first character…
>
>
>
> On Sep 25, 2013, at 8:49 AM, psg <[hidden email]> wrote:
>
>> Thank you for the suggestion.
>> I was thinking about this as well. I didn't use it, because my data is
>> relatively big (~1300 items).
>> Initially I was loading all items without parents on the root level, but the
>> performance was not good.
>>
>> Then I switched to artificial nodes that group the items by their first
>> character (A,B,C, etc.), so initially you only see the groups. This improved
>> the performance dramatically. I am afraid by turning autoExpand on, I'll be
>> back to bad performance.
>>
>>
>>
>> --
>> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Tree-bug-related-to-mayHaveChildren-and-pasteItem-with-Observable-store-tp3999377p3999419.html
>> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
>> ________________________________________________________
>> Dojo Toolkit: http://dojotoolkit.org/
>> Tutorials: http://dojotoolkit.org/documentation/
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>>
>> [hidden email]
>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
> ________________________________________________________
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
>
> [hidden email]
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

shane
Definitely verify that’s the correct workaround before doing any of that work though :-)



On Sep 25, 2013, at 9:08 AM, Shane Green <[hidden email]> wrote:

> Or use a subclass of TreeNode that doesn’t propagate expand() to the super class if the tree is loading.
>
>
>
> On Sep 25, 2013, at 9:00 AM, Shane Green <[hidden email]> wrote:
>
>> You could try turning on auto-expand after the initial tree has been loaded, so it’s only in effect for dynamically added nodes, if that works.   You still have an issue if you’re adding to collections with large numbers of children, but less so than starting out with the entire tree expanded.  I’m not sure that would work, but then again, I’m not even positive I’m recalling the correct workaround (although I’m pretty positive it was the workaround for this problem).
>>
>> Yes, I could see creating an “Orphans” group that may have its children grouped by first character…
>>
>>
>>
>> On Sep 25, 2013, at 8:49 AM, psg <[hidden email]> wrote:
>>
>>> Thank you for the suggestion.
>>> I was thinking about this as well. I didn't use it, because my data is
>>> relatively big (~1300 items).
>>> Initially I was loading all items without parents on the root level, but the
>>> performance was not good.
>>>
>>> Then I switched to artificial nodes that group the items by their first
>>> character (A,B,C, etc.), so initially you only see the groups. This improved
>>> the performance dramatically. I am afraid by turning autoExpand on, I'll be
>>> back to bad performance.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Tree-bug-related-to-mayHaveChildren-and-pasteItem-with-Observable-store-tp3999377p3999419.html
>>> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
>>> ________________________________________________________
>>> Dojo Toolkit: http://dojotoolkit.org/
>>> Tutorials: http://dojotoolkit.org/documentation/
>>> Reference Guide: http://dojotoolkit.org/reference-guide
>>> API Documentation: http://dojotoolkit.org/api
>>>
>>> [hidden email]
>>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>
>> ________________________________________________________
>> Dojo Toolkit: http://dojotoolkit.org/
>> Tutorials: http://dojotoolkit.org/documentation/
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>>
>> [hidden email]
>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>

________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
psg
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

psg
Hey thanks a lot!!!

Your suggestion to turn on the autoExpand after the Tree loads worked perfectly.
I had to change:

model.mayHaveChildren = function(item) {
    return true;
};
treeWidget = new Tree({
    id: "someTree",
    model: model,
    showRoot: false,
    onDblClick: function(item, treeNode, evt) {
        if(item && item.id > 0) {
            _loadDetailsPane(lang.clone(item));
        }
    },

    onLoad: function() {
        this.set("autoExpand", true);
    }

});
Reply | Threaded
Open this post in threaded view
|

Re: Tree: bug related to mayHaveChildren and pasteItem with Observable store

shane
Awesome!  I remember spending a fair bit of time playing around with that
issue myself, and I tend to agree that it's an issue, or at least a
shortcoming for dynamic trees.  I'm glad that helped!

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of psg
Sent: Wednesday, September 25, 2013 9:38 AM
To: [hidden email]
Subject: Re: [Dojo-interest] Tree: bug related to mayHaveChildren and
pasteItem with Observable store

Hey thanks a lot!!!

Your suggestion to turn on the autoExpand after the Tree loads worked
perfectly.
I had to change:

model.mayHaveChildren = function(item) {
*/    return true;/*
};
treeWidget = new Tree({
    id: "someTree",
    model: model,
    showRoot: false,
    onDblClick: function(item, treeNode, evt) {
        if(item && item.id &gt; 0) {
            _loadDetailsPane(lang.clone(item));
        }
    },
/*
    onLoad: function() {
        this.set("autoExpand", true);
    }
*/
});



--
View this message in context:
http://dojo-toolkit.33424.n3.nabble.com/Tree-bug-related-to-mayHaveChildren-
and-pasteItem-with-Observable-store-tp3999377p3999425.html
Sent from the Dojo Toolkit mailing list archive at Nabble.com.
________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit:
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest