How do I keep the same ID data when moving from one Tree to another and also within the same tree

2,100 views
Skip to first unread message

Christopher White

unread,
Apr 2, 2014, 7:36:49 AM4/2/14
to jst...@googlegroups.com
Hello Ivan, 

First of all may I say thank you very much for a great tree view solution, it has been and is a great experience becoming familiar with the plugin and seeing how powerful a utility it can be. 

The reason for me contacting you is that my application requires that when I copy from one tree to another I retain the original Parent and Children ID's. 

I have noticed that when I copy an item from one tree view to another the ID's change to things like j2_2 etc... 

The nature of my application requires that I retain both the Parent ID and the Child ID's unless the User creates a new Parent Node as these ID's (Parent and Child ID) represent the ID columns in the database from where the tree data is extracted.

I have seen a couple of postings talking about using the plugin  "crrm" which I understand to know be a part of "Core" (correct me if I am wrong) but none of these examples have worked for me. 

I have also read that by setting   "crrm": { "move": { "always_copy": "multitree" } } the original ID's will be retained  but for me this is not the case. I have  included some of the examples I have seen online below but I do not think these are applicable for v3.0 beta 10. I have got the most recent releases for Github... Can you give me any advice on how I may be able to retain the Parent and Child ID's when copying from one tree to another please.. 

Thanks in advance 

Chris 


/****************************************  EXAMPLES BELOW OF POST THAT I HAVE READ RELATING TO THIS ISSUE *******************************************************************************************/


$('#SecondTree').jstree({

"crrm": {
                    "move": {
                        "always_copy": "multitree"
              }
    }).bind("move_node.jstree", function (e, data) {

             var copyNode = data.rslt.o.attr("id");
             data.rslt.o.find("li").attr("id",copyNode); 
}


The source tree must have:
* "dnd" & "crrm" plugs ins like the example does 
* The move.check_move function must be present as well as above 
* We do NOT need the move.always_copy, delete this, not needed here.
The destination tree must have: 
* "dnd" & "crrm" plugs ins like the example does 
* Needed to add the crrm.move.always_copy:true, here. "crrm": { "move": { "always_copy": true } },




/****************************************  EXAMPLES ABOVE OF POST THAT I HAVE READ RELATING TO THIS ISSUE *******************************************************************************************/

Ivan Bozhanov

unread,
Apr 2, 2014, 9:31:29 AM4/2/14
to jst...@googlegroups.com
Hi,
You are right that you cannot use CRRM - this is old 1.0 code.
Unfortunately the IDs cannot be kept automatically, because there might be conflicts which would break the receiving tree. It is up to you to sync them if you want - just bind to the copy_node event (copy_node is always fires for multitree moves, as we cannot be sure that we can remove the original nodes from the original tree) on the receiving tree:
$('#tree').on('copy_node.jstree', function (e, data) {
   // data.original has all the IDs that you need
   // either use set_id on data.node (and all its children)
   // or after syncing to DB simply call data.instance.load_node(data.node.parent); which will reload the node and get all the correct IDs
})

Best regards,
Ivan

Christopher White

unread,
Apr 2, 2014, 10:42:43 AM4/2/14
to jst...@googlegroups.com
Fantastic Ivan worked a dream 

  $(view).find("#organisation_working_area").on('copy_node.jstree', function (e, data) {
                $('#organisation_working_area').jstree(true).set_id(data.node, data.original.id);
            });

Thanks 

Ivan Bozhanov

unread,
Apr 2, 2014, 10:49:49 AM4/2/14
to jst...@googlegroups.com
Using data.instance instead of: $('#organisation_working_area').jstree(true) will be much faster :)

Also keep in mind you might have to process the children too, something like:
for(var i = 0, j = data.original.children_d.length; i < j; i++) {
  data.instance.set_id(data.node.children_d[i], data.original.children_d[i]); // but this is untested I am not sure if it will work properly - test for yourself
}

Best regards,
Ivan

Christopher White

unread,
Apr 4, 2014, 8:15:07 AM4/4/14
to jst...@googlegroups.com
Thanks again Ivan, I had just been trying to achieve this and was about to write you another message when I saw your solution which works by the way .. 

Thanks 

Chris 

Anderson Silveira

unread,
Dec 4, 2014, 12:28:54 PM12/4/14
to jst...@googlegroups.com
Hi Ivan

Im sorry arise this thread. But I would not want to duplicate a topic.

I am recently using jstree in my project and is being very util. Congratulations for works!

But I faced the same problem to change de ID attribute during action on copy_node, somehow the ids are locate with differents place on children. I will explain:

I have two list and I want copy from A to B. For example I will represent the nodes with ids:

Tree A

(3)
|_(31)
|   |_(311)
|   |_(312)
|_(32)
|_(33)

Tree B
(3)
|

And then, when I make the copy of node 31 from tree A to tree B for instance, bind copy_node(how was explain here)

$('#treeB').on("copy_node.jstree", function (e, data) {
      data.instance.set_id(data.node, data.original.id);
  for(var i = 0, j = data.original.children_d.length; i < j; i++) {
  data.instance.set_id(data.node.children_d[i], data.original.children_d[i]); 
}
});

But somehow  the order between childrem list not maintained, here the inspect before change:

data.node.children_d
new ids :                ["j1_12", "j1_13", "j1_11", "j1_14", "j1_15"]

old  ids associates : ["31","33","34","341","342"]

data.original.children_d
["31", "34", "341", "342", "33"]


after change the result is:

data.node.children
["341", "342", "33"]

data.original.children_d
["31", "34", "341", "342", "33"]

data.node.children_d
["31", "34", "341", "342", "33"]

data.original.children
["34", "31", "33"]

Realize the ids children is not equals, have you some idea what is wrong in my code? Another information is my two tree has "sort" plugin configured.

Att,

Ivan Bozhanov

unread,
Dec 5, 2014, 3:17:06 AM12/5/14
to jst...@googlegroups.com
Hi, the children array will be sorted in a different way if only one of the trees has sort enabled, as for the children_d - it will never be sorted in any way.
So if you get the wrong IDs - it is probably because of the sort plugin - in that case you will have to assign the IDs based on some other criteria.
Either store them in the .data property of the node, or use the text property to match one node to the other.

Best regards,
Ivan

Anderson Silveira

unread,
Dec 5, 2014, 7:21:37 AM12/5/14
to jst...@googlegroups.com
Hi Ivan

Tks to answer my question! 

I cant use the text property of the node, because some are equals each other. I did not understand when you said to use data property, due it be lost after pasting too. For exemple, IDs on brackets

(3) Link
|_(31) Folder
|   |_(311) Code
|   |_(312) Name
|_(32) Code
|_(33) Name

And then, is there the one way to assign the IDs with some criteria different of text property? 

I removed sort plugin and persist the problem yet, after change IDs, the result is:


data.original.children_d
["32", "31", "311", "312", "33"]

data.node.children_d
["32", "31", "311", "312", "33"]

data.original.children
["32", "31", "33"]

data.node.children
["311", "312", "33"]

It is strange, children_d are right and children are not.

Ps. So sorry, the last message was shown is wrong values with 341, 342 and 34, were in fact 311, 312 and 31.

Qijie Cheng

unread,
Mar 20, 2015, 4:56:04 AM3/20/15
to jst...@googlegroups.com
the for loop goes well !! Thanks ~.~

在 2014年4月2日星期三 UTC+8下午10:49:49,Ivan Bozhanov写道:

livefrug...@gmail.com

unread,
Jul 9, 2018, 9:34:52 PM7/9/18
to jsTree
It's not working for me..

2015년 3월 20일 금요일 오후 5시 56분 4초 UTC+9, Channely Cheng 님의 말:

livefrug...@gmail.com

unread,
Jul 10, 2018, 4:44:55 AM7/10/18
to jsTree
I think it is only working when children has not their children.


2018년 7월 10일 화요일 오전 10시 34분 52초 UTC+9, livefrug...@gmail.com 님의 말:
Reply all
Reply to author
Forward
0 new messages