#11085 closed defect (fixed)
treeStoreModel's pasteItem return different results when using insertIndex
Reported by: | Jean-Rubin Leonard | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.5 |
Component: | Dijit | Version: | 1.5.0b1 |
Keywords: | tree treeStoreModel Dnd PasteItem | Cc: | |
Blocked By: | Blocking: |
Description (last modified by )
Hi, Consider the following tree:
NodeA |--NodeA1 NodeB |--NodeB1
If I drag and drop NodeB1 squarely on NodeA, the drop part of the DnD happens on the few lines starting at line 256 of treeStoreModel.js.
In the case where there's no insertIndex (drop squarely on a specific node) the store's data gets changed and the method carries on. After that the store's onSet is invoked and receives the item, the attribute, the old Value and the new value as attributes. One can then proceed to see what has changed by comparing old value to new and then doing the proper treatment.
When there is an insertIndex however (instead of DnDing? directly on a node, we used betweenThreshold to add a node as a sibling of one of the children of a node) the treatment seems to be incorrect. The reason for this is that when there is an insertIndex the splice statement changes the array (which changes the store's data, (childItems.splice(insertIndex, 0, childItem);, line 259) THEN the store's data is saved again (store.setValues(newParentItem, parentAttr, childItems);, line 260) What this basically causes is for oldValue and newValue to be the same when the store's onSet ensues.
Hope this is clear. I'm usually around on IRC with a live test case if needed but I can't provide one with this ticket at this moment.
Change History (4)
comment:1 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Milestone: | tbd → 1.5 |
Owner: | set to bill |
Status: | new → assigned |
comment:2 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 12 years ago by
comment:4 Changed 12 years ago by
in trac #10474 the same issue is fixed at store (ItemFileReadStore?) level. I know not all stores are inherited from the ItemFileReadStore?. But in my opinion fixing it at store level is logical. Not at model level. just myHO. Keep up the good work guys
Thanks for catching that, I'll check in the fix