Pending changes is a state in which a row is edited, but not persisted in the physical storage yet. A record row can contain only one pending change at a time, which is one of four modes below:
Each row’s pending changes is stored on its corresponding table which enables pending changes to be consumed in multiple tables (hierarchical) configuration. For more information about batch update support for Hierarchical feature, please read Hierarchical Tables Support.
On top of all, Intersoft’s pending changes mechanism is automatically stored and persisted during any flypostback actions, such as: grouping, sorting, filtering, and many more. This provide user with greater experience to interact with data while at the same time maintaining the current changes simultaneously.
Whenever users make changes to data, add or remove a row, WebGrid will automatically maintain the pending changes status by updating the related user interface elements in the status bar area.
The pending changes status makes it easy for users to understand the current changes state, as well as to perform an action that related to the current changes such as accepting all changes.
Users tend to forget to save changes when they are doing multiple tasks at the same time. With the eye-catching Vista-style notification in WebGrid, that is nothing to worry about. The Vista-style notification will appear automatically when WebGrid lose its focus and pending changes existed.
Better yet – users will be prompted when they are about to leave the page while pending changes existed. This feature is especially useful to avoid changes lost due to accidental hyperlink clicks or browser close.
A record can contain only one mode of changes. Therefore, if you perform several changes on the same mode, the pending changes will merge automatically. If the change mode is different, it will remove the previous changes and set the latest change mode as active. For example: user edits a record then later deletes it. In such case, the previous changes will be undo’ed and the delete pending change is added.
When you press TAB key to edit data and past the last cell of the row, the edited row will be marked as pending changes. The active cell selection will also be set to the next row, which allows users to edit data faster.
WebGrid will automatically lock the auto-increment field to avoid any unnecessary errors and assign “Auto” in the text field to tell user that the cell value is automatically generated.
WebGrid Enterprise comes with the ability to generate key values for auto-generated fields to simulate the database structure in client-side, which enables pending changes to work effectively and reliably.
WebGrid comes with a new setting which focuses the selection to the first editable cell upon a successful row adding operation. This will significantly improves data editing entry process as user doesn’t need to manually select the cell on every new row adding operation. This is convenient under certain circumstances when user needs to input multiple rows.
A row with deleted pending change is locked by default to prevent any unnecessary conflicts and saving errors during the server-side batch update process.
Add pending change rows are always positioned in the last of the table according to the sequence of insertion. This enables user to locate the newly added rows immediately without having to navigate to the last page in the grid and perform editing if needed.
When delete operation is performed in Add pending change row, the row will be removed from the batch update queue instantly as well as its associated pending changes.
SmartBatchUpdate™ includes full support for hierarchical tables configuration which makes it the most advanced and reliable solution for enterprise-class data editing requirements.
It's named SmartBatchUpdate for many reasons and one of them is because SmartBatchUpdate runs globally in WebGrid regardless of what table level the row belongs to. This means you can build an advanced hierarchal WebGrid with SmartBatchUpdate feature enabled.
WebGrid requires the tables to have valid referential integrity, that’s all it needs for batch update feature to work. The referential integrity is usually defined at DataSet level through Relationships object. WebGrid makes use of this information in hierarchical data processing as well as in batch update processing. Through referential integrity between each table, WebGrid will be able to store appropriate changes such as edits or deletes in the child table.
Cascading inserts essentially means that newly added rows in each linked table should be submitted at the same time in a single update process. From end user point, they require the ability to create the new row in parent table and continue to add its child rows without having to physically create the parent row in the server.
As illustrated in the above image, user can quickly add a new data in the Customers table, drill down the record (even though it’s not existed in server yet), add two new records into Orders table, drill down the Order record again, and finally add records to the Order Details table. The cascading inserts is made possible as SmartBatchUpdate™ smartly virtualizes the referential links and structure of each table, and intelligently generates the unique auto-generated values in the client side. Supporting int32 and GUID auto increment data type, WebGrid will automatically show AUTO for the auto generated fields. When the Accept Changes command is invoked, WebGrid will automatically translate the new identity with the one resulted from the database inserts and map it recursively to the linked child rows.
SmartBatchUpdate™ compared to other similar solutions. It pushes the standard bar higher by providing the ability to perform any WebGrid’s FlyPostBack actions without losing all pending changes. This means user can perform grouping, sorting, filtering, paging, or simply refresh the grid, while at the same time performing multiple pending changes.
Automatic changes preservation also opens up to many previously impossible to be done scenarios. For instance: user is now able to edit a row in page 1, navigate to page 3 and make some changes, and go back to page 1 without losing the pending changes.
Searching for the right data within millions of data can be painful. WebGrid streamlines this operation so that user can easily search what they want, either by text, or by value. All done with simple property set.
This is the most fundamental and crucial feature in SmartBatchUpdate as it involves saving your pending changes rows into the physical database. By default, WebGrid will automatically save all submitted pending changes to the intermediate data source which holds the objects during the binding process. This automatic updating also supports nested hierarchical tables linked through referral integrity.
In addition to the automatic update processing, SmartBatchUpdate also introduces BatchUpdate server-side event. When bound to non-datasource control, such as: ADO.NET data set and data table, you can write your own code to handle the update process. OnBatchUpdate server side event provides BatchUpdateEventArgs in the event argument, which is useful for developers who would like to customize the physical updating process, such as in the case of custom object binding.
What about hierarchical traditional binding? Similar to the traditional binding, you're required to handle the OnBatchUpdate server-side event manually.
SmartBatchUpdate also offers the partial error handling feature. Partial error is the state when there are some erroneous rows in all submitted pending changes. The idea of this feature is to return all error rows only, instead of returning all rows and user has to redo all changes again. This saves user from editing nightmare especially under certain situations when user has made hundreds of changes and there are some errors in it.
As in every major release, WebGrid always maintains its high compatibility with existing features. However, there are certain conditions where the enhancements aren’t applicable due to behaviors conflict.
SmartBatchUpdate™ is designed to support these following WebGrid's features:
The high compatibility means that implementing a batch update feature in your existing WebGrid is as simply as replacing the assemblies and enabled the new SmartBatchUpdate property.
All pending changes operations invoked from WebGrid’s user interface are also using the same set of APIs and interfaces. The result is a powerful and highly extensible client side batch editing architecture, which enables developers to further extend the functionality to address their complex business requirements. Please refer to WebGrid’s online documentation to see the complete set of new classes, methods and client side events.
As in the client-side programming, WebGrid also introduces a new set of server-side classes and methods. This enables reliable synchronization between client-side and server-side, which results in consistent interfaces and elegant objects design. Please refer to WebGrid’s online documentation to see the new set of server-side classes and methods.