In the Data Moving Plug-in validation rules and error handling are coded with the usual Asp.net Mvc toolds, such as Data Annotations (or Fluent validation), by adding errors to the ModelState, etc. Also client side validation is based on the jquery validation plug-in. However, all these tools have been enhanced in several ways.

First of all, server errors are returned also as a result of JSon updates, and dispatched to the right places in the UI (thanks to the updatesManagers that handle the updates). Moreover, also elements that are detached from the Dom, and rendered again by instantiating  client templates “remember” their error state thanks to parallel data structures that takes care of this “job”.

Probably, the more interesting enhancement is “error bubbling”. What is “error bubbling”? Suppose you need to report an error to the property AllProgrammers[1].EMail, that is to the Email property of the second programmer of a programmers list. Well, if the grid has no visible Email column, the error can't be shown! In order to overcome this problem the error is bubbled up to the whole entity level:  AllProgrammers[1]. Now if we add an error column to the programmers grid the user can see the second programmer has an error:

Since we put m => m the error column is triggered by whole entity level errors. This way also errors in fields that are not shown in a grid row can be signalled to the user. Error bubbling is useful also in TreeViews/TreeGrids because an error happening in a child entity is signalled also in its father entity, so the user may open the right branch of the tree to find the children entity in error. Below an example of error bubbling in a TreeGrid:

Error bubbling is automatically applied to both the errors returned by the server and to client side validation errors.

What if the user want to know exactly which among the fields that are not shown in the grid is in error in order to correct the error? Simple! He just need to show the entity in error in a detail view. This way, thanks to the errors synchronization behavior between main views and detail views provided by the Data Moving Plug-in he can see the error in the detail view!

Another interesting feature is Error Filtering. All Data Moving Plug-in controls that have been enhanced with a retrievalManager, have error filtering capabilities. This means, they respond to a “show just entity in error” filtering command that may be issued with a button in a toolbar. This way the user can review all errors by browsing the list of all entities in error.

Everything works properly because the Data Moving engine “remembers” the error state of a field also if the entity the field in error belongs to is removed from the Dom, for instance, because of paging.

In order to minimize the round-trips to the server the Data Moving Plug-in offers the possibility to add entity level validation rules, and whole ViewModel validation rules directly on the client side.