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.
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.
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
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.