Greetings and thanks for your reply,
I'll list my replies to your replies using the same numbering:
1- The performance argument concerning serializing data to the client (as JSON) shouldn't be given high weight because anyway, ASP.Net grids (both yours and Microsoft's) used to serialize their data items (or at least, the data keys) and UI items to the view state to use them later in display, update and deletion operations.
ASP.Net Web Forms was designed to serialize and deserialize data back and forth between the client and server, and nobody can avoid this.
Why not implementing the RadGrid so that, when it's set to use the batch mode, it serializes its items only as JSON, and doesn't depend on the view state. This will later enable using both server side and client side rendering (for example, render on the server on initial data bind, and later use the JSON data to render on the client).
If you consider it thoroughly, you will find out that -like it or not- this feature has to be implemented.
Consider the case when the user clicks the "Save Changes" button, and all changes are sent to the server. Is it guaranteed that the save operation will succeed? No, it may fail or not pass validation rules. Then I'll need to do data binding with the data source, get the user modifications, and merge them to revert the grid back to its state when the user clicked Save.
My next task here in my work is to implement this state persistence feature, and I think that it has to be supported natively.
The issue I mentioned
was not resolved, but I marked it as answered, because it really was answered. The answer is that this is a bug and will be fixed in a future release. But currently this can't be done. Because the batch mode grid stores data in TD's, we can't make a lookup column that displays some data (name) with other underlying data (key or id). And I had to break my lookup into two columns.
2- Computed columns usually use simple expressions that can be calculated on both client and server. I had created the feature myself, but it will be neater to be built in using the currently available computed columns.
3- I'll be glad that the row deleted event issue will be handled on next releases. I'll post my suggestions about the API whenever I face an issue to not bloat this thread.
4- This is related to point 1, and I think that the difference in our point of views is caused by that the functionality of batch editing is something brought from modern single page applications, and seems foreign to ASP.Net which depends on doing a post back on each operation. My straightforward thinking as an ASP.Net developer went to that batch mode grid will maintain its state between post backs as ordinary grids do. Liked its performance penalty or not, we will have to implement this feature some way or another.
5- I hoped there're detailed documentations for both the client and server APIs that list the members of every class with detailed description for every member and method parameter and a brief example on each, in the same manner of Microsoft .Net and AJAX documentations.
The current content of Telerik mixes tutorials, samples, and documentation. The client side API docs lacks description for parameters. The meta comments in Telerik assemblies miss some members. In many occasions I find no reliable way to determine what certain method or property does, and I resort to fiddling, inspecting using the console, or reading minified JS code.
6- Your argument against external libraries applies to jQuery too. Telerik uses jQ although jQ has bugs too and its team take decisions that may affect you (like deprecating IE6/7/8 on the 2.x branch).
Almost all the MV* frameworks are open source, so you needn't wait until certain bug is fixed, moreover, they are mature and robust, so, you won't see grave API changes between versions. I use Knockout since V1, and still my old code can run without problems on the current version.
7- Logically, a delete operation shouldn't be accompanied with validation, because data will be trashed anyway, why mind with validating them?
Here's an excerpt from the BatchEditingManager.
As you can see, the first step done is calling this._validate which validates only the current row (It uses a validation group specific to the grid). What made me collide with this behaviour is that I set EditType="Row" and OpenEditingEvent="Click", so when I click a row to delete, it's open for editing, and its validators are triggered when deleting. When I try to delete blank new rows I fail. I had to write another hack to get around this.