Our ASP.NET WebForms and MVC TreeList controls have a very cool feature added in their v18.1 release. It’s Batched Editing!
You might already be familiar with this feature in the ASPxGridView. Batched updates eliminate unnecessary roundtrips to the server, and as a result of that, it greatly improves the performance as well as the end-user experience when modifying a lot of data in different nodes. All changes will be submitted in on callback and you can process them in one go on the server.
We developed the TreeList in a similar way as the GridView so this also means the the API and features work in a similar way as the GridView. There are obviously some differences which I’d like to point out in this post.
Enabling Batched Editing
If you want to enable batched editing, the first thing you need to do is change the TreeListSettingsEditing.Mode property to Batch. The next thing you need to do is implement the BatchUpdate event. This event receives a list with deleted, inserted and updated nodes that you can use to update the underlying datastore.
If you don’t implement this BatchUpdate event, the regular NodeInserting, NodeUpdating and NodeDeleting events will be raised for each node. This is not recommended when using Batch Editing.
What about inserting cascading child-nodes?
When inserting a child node of a parent node that already exists in a data source, it uses the parent node's key field name. The newly inserted child node doesn’t have a key field until it is saved by clicking the Update button in Batch edit mode. This is a problem when a new node has new child-nodes as well in the same batch update. Those child-nodes don’t have a parent id yet.
To overcome this issue, the TreeList has a new method SetBatchEditInsertedNodeKeyValue. You need to assign the key of the newly inserted node so the row in the datastore can be added automatically.
To see how this works, check out the demo on Batched Editing.
What about cascading deletes?
If you want the TreeList to do cascading deletes, all you need to do is set the SettingsEditing.AllowRecursiveDelete to True.
There is a small caveat here:
The underlying datastore needs to support cascading deletes as well.
If you enable recursive deletes on a datastore that doesn't support this, an exception will be thrown at runtime and you will need to handle the recursive deletes manually.
What do you think?
Let me know what you think of this feature by replying on this article.
Try it?
Did you know that you can test this feature together with all the other exciting new DevExpress candy even if you’re not a customer (yet)?
Feel free to download a free 30-Day trial versionincluding technical support of our award winning controls!