Save datasource change when needed

[Ying]

Hi there,

I have a treegrid bind to a restdatasource. Is it possible to have a save button to save previous update/delete/add actions when needed rather than submitted by the datasource automatically?

The tree would be changed very frequently and users might want to cancel all operation (i.e. drag and drop/ add new tree node) if they made a mistake. Currently, any operation like this, datasource would automatically sends data to the server. I'm trying to add a save button to send updated nodes to the service and a cancel button to cancel all operations to put the tree back to what it was.

Is there any way to do similar thing like this? Many thanks for your help.

[jay.l.fisher]

We've done something similar and the basic technique is to add FolderDropHandlers to handle the drag and drop yourself on the client side. Then do the actual save to the database when the user clicks a Save button. It isn't simple, and there might be a better way, but it works.

I've attached our code if you want to take a look. The specific datasources we're using add a level of complexity (legacy stuff) that I hope you don't have to deal with so I've not included those.

In our case, we present two trees side by side. One has the complete set of possible nodes (less those that have already been dragged across to the other tree), and the other has the ones that have been dragged to it. There is no requirement to add an altogether new node. We just need to allow dragging and dropping from the tree on one side to the other.

So it is somewhat of a special case, but it might give you some ideas on how to do what you need.

[bbruyn]

Is setAutoSave not supported on a treegrid?

[Isomorphic]

It's supported on a TreeGrid, but it doesn't influence whether saving via drag and drop is immediate - it's for inline editing only.

Jay's code has some details that make this look more complicated than it is. The nutshell is, use this sample of tree-to-tree drag and drop, but create the Trees by fetching data using DataSource.fetchData() instead of the hardcoded data shown in the sample.

To save, do a series of updateData() calls on the DataSource. You can figure out the changes a number of ways, but one is to keep a copy of the original tree data around and compare it to the state of the trees when the user clicks save.

[Ying]

Thanks for all of you for such a quick and helpful reply. This should give me a starting point. If I use FolderDropHandlers as Jay said, I can have a collection of changed records to run updateData(). Our tree is very basic but pretty big with loads of nodes and probably will take long time to loop and compare 2 copy of trees. But keep a copy of orginal tree data is useful for the cancel button.

Any idea how to avoid the datasource send drag and drop update immediately? I used the restdatasource with all four bind operations. I assume I'll need to keep the datasource unchanged as updateData() call would need them. But how can I avoid datasource auto sends update?

[jay.l.fisher]

It has been a long time since I looked at that code, but I believe it is the event.cancel() call in the onFolderDrop methods that cancels the call the to server.

[Ying]

It has been a long time since I looked at that code, but I believe it is the event.cancel() call in the onFolderDrop methods that cancels the call the to server.

Thanks Jay for your reply. I've tried this before after reading through your code. The event.cancel will cancel the drop action completely and put the dropped node back to where it was.

In my case, I'm trying to allow the UI reflect the change (nodes been dropped in to a new folder) but avoiding call the server until users click the save button.

Thanks again for you help.

[jay.l.fisher]

The key piece you might be missing is treeGrid1.setData(dsTree). Calling setData fills the tree with local client data so it doesn't try to send updates back to the server.

[Ying]

The key piece you might be missing is treeGrid1.setData(dsTree). Calling setData fills the tree with local client data so it doesn't try to send updates back to the server.

I see your point. This could be the final option if there is no other work around.

I've bind the tree to a restdatasource and all nodes load on demand. I was hoping I can stop the datasource auto update operation and still use the DataSource.updateData() to handle the update operation when needed.

[Isomorphic]

The reason the Showcase sample doesn't automatically save on drop is that neither TreeGrid has a DataSource. If the trees are not huge, this is the simplest way to do things.

If you want either of the trees to have DataSources and use load on demand, this becomes more complicated because you are trying to maintain a list of modifications to partially loaded data.

In this case:

1. use event.cancel() to prevent automatic saves on drop

2. use DataSource.updateCaches() to tell the trees about nodes being removed from the left tree and added to the right (or vice versa).

In this implementation, it can be tricky to figure out the set of changes at the end when the user saves, so it's usually better to keep track of changes incrementally (each time a drop occurs).

[Ying]

Thanks Isomorphic, this is very useful and I think I know what to do next now. Thanks again for your help.

The reason the Showcase sample doesn't automatically save on drop is that neither TreeGrid has a DataSource. If the trees are not huge, this is the simplest way to do things.

If you want either of the trees to have DataSources and use load on demand, this becomes more complicated because you are trying to maintain a list of modifications to partially loaded data.

In this case:

1. use event.cancel() to prevent automatic saves on drop

2. use DataSource.updateCaches() to tell the trees about nodes being removed from the left tree and added to the right (or vice versa).

In this implementation, it can be tricky to figure out the set of changes at the end when the user saves, so it's usually better to keep track of changes incrementally (each time a drop occurs).