Tree: if two trees have same store then drag should move item, not copy it

[youngho]

Hello,

When dragging/dropping within the same tree, drop calls model.pasteItem() to be called instead of model.newItem(), effectively moving the item.

I think the criteria for calling pasteItem() should be whether or not the two trees share the same store.

[bill]

Hi youngho,

Hmm, well I'm sure there are cases when the designer will want to copy, and other cases where the designer will want to paste (ie move) the item.

The thing that concerns me is that if the two trees share the same store, even with your patch, dragging an item from Tree 1 to Tree 2 typically won't make the item disappear from Tree 1.

So I'm not sure that this patch helps much but I'll consider changing it for 1.3. Can you explain how this patch improves your application? After this change, dropping onto Tree 2 doesn't remove the item from Tree 1, right?

[youngho]

Replying to bill:

Hello Bill,

I am very sorry about my short English.

Can you explain how this patch improves your application?

Our one of typical application is trashCan. Yes, It can be made a trashCan within same tree. But our designeer want to make it as Second Tree.

After this change, dropping onto Tree 2 doesn't remove the item from Tree 1, right?

If this patch applied than the Tree1 item will disapper when it dropping onto Tree2. I make test_Tree_Dnd.html patch also.

Thanks,

Youngho

[bill]

OK, so you have two trees pointing to the same data store but because of filters they display different data? (And no values are repeated?)

[youngho]

Replying to bill:

Yes,( I don't know how can I distinguish which items show in Tree1 or Tree2 without tree filtering. )

If we use ForestStoreModel?, than we can achive same effect without any change of categories.js and more simple. I think we need some extra modification ( OnDndDrop? method ) to add some attribute in order to filtering which item shoud be show for example 'deleted:true/false' to the items.

[youngho]

Replying to youngho:

At this moment I think the detail draggng/dropping example between trees has a little customized issue.

But the patch is correct and give more flexibilty to the users I think.

[bill]

bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4

[alle]

I think that adding dndMoveOnSameStore (default false for back-compatibility) to tree for easy behavior configuration can be best solution.

[bill]

Well, you can get pretty easy configuration by overriding pasteItem(). There are three possible configurations (or more?) that a developer might want, so it would be more than just a simple flag if we allowed customization by flag setting:

• change the item's parent (remove reference from old parent, add reference from new parent)
• item is added to new parent and keeps old parent (item now is referenced from two parents)
• new item is created as copy of old item

Anyway, I will check in a fix to make the default behavior to reparent the item (ie, move).

[alle]

In general if number of behaviors is defined and not big I think that customization by flag setting is better because don't need a developer skilled in dojo.
I think third option is less common and final non technical user usually don't see differences by copy. Move or copy behavior are defaults behaviors in dnd too.

I think we can let copy creation to overriding pasteItem() and allow customization by flag for copy/move.
My 2 cents.

[bill]

Oh, this was fixed by [18123] but it didn't register here.

I'll think about adding a flag, and also let's see if anyone says they need it for their application.

[bill]

(In [19108]) Avoid failure when running entire regression suite on IE6, where the first mouseMoveAt() moves to the fruits node rather than the vegetables node. Refs #7651.