Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#17465 closed defect (invalid)

Tree: bug related to mayHaveChildren and pasteItem with Observable store

Reported by: [email protected] Owned by:
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.9.1
Keywords: Cc:
Blocked By: Blocking:


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.
  1. Observable Memory store with:

2.a. "getChildren" method querying with {parentId:} 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.

  1. ObjectStoreModel? with "mayHaveChildren" method that returns true based on the exact number of children (no queries).
  1. 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.

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"))

Change History (6)

comment:1 Changed 8 years ago by [email protected]

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.

comment:2 Changed 8 years ago by bill

Resolution: invalid
Status: newclosed

This is an error in your code. You made mayHaveChildren() return false for a node that may (in the future) have children.

comment:3 in reply to:  2 Changed 8 years ago by [email protected]

Replying to bill:

This is an error in your code. You made mayHaveChildren() return false for a node that may (in the future) have children.

I still think it is a design limitation on the tree. It is covered partly in enhancement request 11065 (against dojo 1.4.2). 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 big set of items large majority of which don't have sub-items. But any of them can be configured to have children. 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.

comment:4 Changed 8 years ago by Kenneth G. Franqueiro

While I agree that this isn't something to be fixed on Dojo's end, I don't entirely agree with Bill's rationale, since it doesn't make sense to show an expando on an item that doesn't currently have children, even if it eventually will. Then every item in a modifiable hierarchical store would need to return true at all times, which is wholly inappropriate. Look at any file explorer (windows explorer, finder) and find me *one* that *always* shows expandos on folders in the tree view even when empty. Forcing users to hunt and click and play whack-a-mole to see which expandos are actually meaningful and which actually aren't is not good UX.

I would think the way to resolve this will involve calling notify for your parent item when the child item changes, in order to get consumers to re-render it, since otherwise there's no way to indicate to the store that the result of mayHaveChildren needs to be re-computed.

comment:5 Changed 8 years ago by bill

I just meant that it's working as designed (and documented). I agree it would be nice if the expandos show up only when needed. I think this is covered by #9413.

comment:6 in reply to:  5 Changed 8 years ago by [email protected]

Just wanted to post here a hint that was provided by Shane in the mailing list - to return true in mayHaveChildren and turn on the autoExpand after tree gets loaded.

Here is the full thread

Note: See TracTickets for help on using tickets.