Looking for rollback function

1,811 views
Skip to first unread message

Michael S.

unread,
Jan 13, 2014, 7:54:32 AM1/13/14
to jst...@googlegroups.com
Hi,

I'm using jsTree in version 1.0-rc3. Everthing works fine.

Now I'm trying to migrate to version 3.0 and I'm missing the rollback function.
In the running version (1.0) there was a function like $.jstree.rollback(data.rlbk).
I used it for validation issues after "move_node". If the synchronisation via web service to my database failed, the tree should be undo the move of the node.

Is there still a function/simple way to do an undo/rollback (e. g. for move_node)?

Best regards,
Michael

Ivan Bozhanov

unread,
Jan 13, 2014, 8:37:12 AM1/13/14
to jst...@googlegroups.com
Provided you are using the state plugin - just use data.instance.refresh(); - that will fetch the tree from the server and restore open nodes and selection. You can also do it manually using get_state() and set_state(), and you could also use a param to the refresh function to refresh only a given node if that is what you need.

Best regards,
Ivan

Temuri Imnaishvili

unread,
Jan 23, 2014, 3:49:34 PM1/23/14
to jst...@googlegroups.com
Ivan,

I think there's a bug in data.instance.refresh().

I'm firing AJAX calls on "rename" event and I would like to roll back the state if there was an exception thrown by the backend.

Actually, from what see, the problem lies on "_load_node" function - "this.settings.core.data.children" gets unset in "_append_json_data" by "dom.children = [];" line.

Because of it, when I fire "data.instance.refresh()" the tree is reconstructed with only the Root node.

Thoughts?

Thanks!

Ivan Bozhanov

unread,
Jan 24, 2014, 9:19:11 AM1/24/14
to jst...@googlegroups.com
Sorry - I cannot follow - can you provide me with an example. Children should be cleared as load_node loads them again and reparses what you pass in. Show me your config & data so that I can reproduce.

Best regards,
Ivan

Ivan Bozhanov

unread,
Jan 24, 2014, 11:10:11 AM1/24/14
to jst...@googlegroups.com
There was a bug with refresh that prevented the event from firing - that is fixed now - maybe that was the cause of your problems too? Not sure about it though.


23 януари 2014, четвъртък, 22:49:34 UTC+2, Temuri Imnaishvili написа:

Temuri Imnaishvili

unread,
Jan 24, 2014, 12:35:12 PM1/24/14
to jst...@googlegroups.com
Ivan,


Click any node and press "r" key. The tree will re-render with only root node.

It goes right into "var renameNode = function(node, el)" where "this.refresh()" is fired.

1. In this example "refresh" is fired, essentially, before the tree could be modified. I don't even get to rename node UI. How do you expect "refresh" to act as a roll back when there's no more JSON data in "this.settings.core.data.children".
2. Have a look at AJAX call in "on('rename_node.jstree')" - I'd like to trap server-side errors in "error" callback and roll the tree back. However, it is unclear to which state exactly should the tree go back, and it does not supply "before" state to event handler (as it did in V1 using "data.rlbk" key).

Does that explain the problem?

Thanks!

Ivan Bozhanov

unread,
Jan 25, 2014, 1:17:35 AM1/25/14
to jst...@googlegroups.com
I believe you are calling refresh before "edit" so that I can see the problem? I did and I added a fix in the repo - pull the latest source or wait for beta5 later today.

Best regards,
Ivan

Temuri Imnaishvili

unread,
Jan 27, 2014, 11:51:58 AM1/27/14
to jst...@googlegroups.com
Hi Ivan,

> so that I can see the problem?

Yes, that's right. Your fix did address the issue.

However, the problem with "rollback" is still there. It looks like you no longer have the rollback functionality, the way it was working in V1 (which, BTW worked great).

"refresh" function is not the same as "rollback".

Consider the following usecase.

1. AJAX calls are fired each time a Tree changes its state - DND, rename, creation, removal of nodes.
2. Backend code maintains the DB state and checks for external factors (e.g., validation).
3a. External factors may cancel the operation performed client-side (e.g, a node should not be deleted until dependent records are cleared first).
3b. Backend execution errors should propagate to client side, informing the user about the problem
4. AJAX "error" callback is fired when something goes wrong
5. The Tree should revert to prior state (a rollback is performed)

Using "refresh" in AJAX error callback does not address the issue. Consider this situation (the same usecase above):

0. INITIAL TREE STATE
1. A new node is created successfully
2. Some node is moved to new destination
3. An attempt to rename a node meets rejection by the backend (say, ACL has denied access).

Issuing refresh in "error" callback after step 3 would roll the entire tree back to state 0, results of steps 1 and 2 will be discarded.

The root of the problem is that the data you're using for "refresh" isn't maintained throughout the tree modifications.

Thanks!

Ivan Bozhanov

unread,
Jan 27, 2014, 12:27:01 PM1/27/14
to jst...@googlegroups.com
For me it would be completely wrong to propagate the state to the server using "batches" ... refresh should get you back to point 2 in your example. If your tree and logic is correct those changes would have been persisted to the backend and the refresh call would simply reload all open and selected nodes from the backend.

The reason rollback was removed is exactly because it created a middle space between client and server which was a complete mess to maintain - it is always easier to update from the server if an error happens (let's hope that is a rare event) - that way you are sure the client has what the server has ... otherwise consecutive but async operations may fail simultaneously, which would leave you in a conflicted state (one of the rollbacks would assume the other operation succeeded, just because it failed later, and if you restore from that object you could lose an operation that succeeded in the mean time).

The other reason the rollback object was removed was the insane amount of memory it consumed for larger trees (as a whole copy of the tree would be kept in memory for every function call that is made).

Anyway - if you want to recreate the rollback functionality you could use the get_json function ... although I would advise against it. I believe a proper structure of callbacks and JSON data configs would make refresh a better option.

Best regards,
Ivan

Philipp Meier

unread,
Jul 2, 2015, 5:52:35 PM7/2/15
to jst...@googlegroups.com
Hi

If I would use get_json to replicate rollback functionality, what function do I use to "rollback" the tree to the json state? Do I have to create a whole new instance of the tree with the create function?

Thanks,
Philipp

Ivan Bozhanov

unread,
Jul 2, 2015, 7:15:37 PM7/2/15
to jst...@googlegroups.com, nevi...@gmail.com
Use "refresh" to fetch the fresh instance from the server.

Best regards,
Ivan

Soar Yap

unread,
Jun 19, 2020, 4:08:38 PM6/19/20
to jsTree
Hi, i think this should be included in the readme/jstree website. I had a hard time searching up on how to undo an operation when the ajax call fails.
Reply all
Reply to author
Forward
0 new messages