WebDataGrid Batch Updating

[Infragistics] David Young / Wednesday, November 2, 2011
Updating can be a big part of certain grid scenarios and now the ASP.NET WebDataGrid supports batching all updates on the client.  The great part about this is that the number of postbacks can be reduced to one to push all of these changes to the database.  If the updates are handled manually, all of them could conceivably be done with one data source query.  To take advantage of this new functionality,  turn on the new property on the Editing Core behavior called BatchUpdating.
 
ASPX:
Code Behind:
 
Setting this property to true will batch row edits, deletes, and additions.  It is important to note that not handling the RowUpdating/RowUpdated server events on the Editing Core behavior no longer has any effect on whether row updates are batched on the client; the new property must be set to true.  This now will let you batch update  and handle the events on the server.  It is also important to understand exactly what is done with the batched updates.  All updates are saved on the client until any grid or page postback happens which will cause all updates to be committed to the database. 
 
Some new functionality is introduced with this new feature, too.  The ability to undo an update can be done when control-Z is pressed on an edited or newly added row or when the Undo button is clicked over a deleted row.  We mark a row for deletion by applying a css to it and show a button when  the mouse hovers on it or when using the keyboard to navigate to that row as it can be seen in the image below.  Note that no cell in the deleted row is active at any time.

 

Two new events are added to the Editing Core behavior called BatchUpdatingUndoing and BatchUpdateUndone.  These fire when the undo operation is being performed by the end user.  This is a good place to perform validation as to whether the undo operation should proceed.  
When batch updating is on, a row is marked as edited as soon as one value is changed, however the events will not fire until the active row is changed (this applies to cell editing, not the row edit template).  A newly added row is also given two css classes.  This allows us to use CSS 3 animations to fade in the new row.  This will be visible in Internet Explorer 10 or another modern browser such as Firefox or Chrome.
Edited Row:

Added Row:

 

Once you have all of these updates on the client, how does one go about committing them?  Off of the editing core behavior on the client, it is possible to retrieve an array for updated rows, deleted rows, and added rows.  Calling commit() will send the updates to the server via a grid postback.

Gotchas: When a new row is added, it is important to remember that it will not be sorted, filtered, or grouped until a postback occurs and the grid rebinds to its data.  Additionally, if there are template columns, those cells are left empty because the template resides on the server.  You could handle the client rowAdded event to insert html in those cells.  The ‘-ed’ events will fire right after the ‘-ing’ for updating, deleting, and adding when batching is on and nothing will fire after the postback to commit the changes.