Complaints and suggestions about the batch mode

[أشرف]

As the managers of the company I work in are very interested in the newly introduced batch mode editing feature, because they want to achieve this behaviour in our new project, I was very involved in using and hacking RadGrid to achieve every feature they require.

After a period of this involvement, I'd like to publish about some of the issues that hindered me, and one or a couple of suggestions to enhance the feature.

1. RadGrid in batch mode doesn't serialize its underlying data source items to the client to be able to manipulate them easily there. Although GridTableView has a dataItems collection (whose name seemed attractive to me), the collection in fact doesn't hold the data records (they're set to null). In fact, the grid uses the DOM as the store of data which made the code complicated (I mean Telerik's code and mine), made the grid hard to extend and manipulate, and introduced problems like this one.
2. Based on point 1, in which I mentioned that the grid is hard to extend, I'll provide an example: My management asked me to create computed columns and aggregates that are updated while on batch mode. Currently, the available computed columns and aggregates don't work while on batch mode, so I had to write the feature myself. I thought that the task is easy, and will be just a call to reduce on the dataItems array, but it turned out that dataItems doesn't hold the data (maybe this collection is used in other modes. When binding to a data service for example, but I'm not sure), and I had to use some combination of getCellValue and getCellByColumnUniqueName and take care of that these functions read the values from the DOM, so when a row is open for editing it won't be involved in the aggregation until it's closed. When I wanted to write code to recompute the aggregates when a row is deleted, I found that there's no "row deleted" event! The grid has a rowDeleted event but it's not triggered on batch mode. It tried the disposing event on data rows, but it's not reliable, because disposing is different than deletion, and I found my code called unexpectedly. To resolve the issue, I created a dummy rowDeleted event that I call by my code when the user deletes a row, and also consider using something fancy like DOM mutation observers to track row deletions. I'm keen on this because I have some other features that requires to be notified by row deletions.
3. As clear in point 2, the API is not rich, and I got the impression that the batch mode feature was half baked. Many times, I find myself in need to do direct DOM manipulations to achieve what I thought should be part of the API of any grid.
4. Based on point 1, the grid doesn't participate in ASP.Net post back operations because its data is in the DOM, not in a structure that can be serialized to a hidden field so that the data is not lost when another control causes a post back. Currently, a batch mode grid needs to be the issuer of the post back operation that saves the data. I have to bind my general save button to call batchManager's saveTable method, otherwise the data will be lost.
5. The documentation is not sufficient. It just states some methods (not all) without descriptions of the parameters and examples. I waste long time inspecting the objects using browser developer tools, and read the source code of their methods to understand how everything works.
6. I wonder why Telerik tries to create this whole thing from scratch. Why not use an MV* framework like Knockout or Angular to create a functionality like batch mode editing, in the same way that Telerik currently use jQuery? Using such a popular and powerful framework will make the component powerful, cleaner, and easier to extend, which will benefit you and us.

Maybe there are other issues that I wanted to write about, but these are on the top of my mind now.
I know that batch mode is a new feature that was added to the current release, but I found it lacking some expected basic behaviours.
I hope it will become better and better in future releases.

Regards,

[أشرف]

Another weird issue: When I try to delete a row using batchEditingManager.deleteRecord the required field validators are triggered! I viewed the code of this method to find that the first thing it does is to validate the row. I wonder why validating a record that's about to be deleted?

[Angel Petrov]

Hello Ashraf,

I want to start by thanking you for taking an interest of the new batch editing functionality that RadGrid provides.

Now I will go through the listed points and try to answer the questions as descriptively as I can:

1. Indeed your observation are correct, the grid uses the DOM to create it's data items. The reason behind this is that if the data is being serialized and transferred from the server to the client in some scenarios this will result in a performance decrease since a large amount of data is send. And since this is not desirable the data is extracted directly from the DOM. As for the issue described in the link it is already resolved and should not reproduce it with the latest version of the controls.
2. The calculated column issue a combination of the batch edit mode and column designs. Now currently the column values are calculated on the server by a given expression. However not all expressions may be calculated in the same manner on the client. Integrating a solution which will not work consistently on the client and server is not and should not be a followed practice. That said I would recommend following the approach provided in the forum post which you have already pointed. Note that we have already logged the problem related with the RowDeleting event and it's firing and our developers will do their best to include a fix for the next official release.
3. Regarding the API, by my opinion it provides the needed set of methods and events that can help a developer accomplish it's task. You can change the cells values, save the changes, open cells for edit and perform other data related manipulations by using only the built-in methods. Additionally four batch edit events are exposed which allow the developer to handle complex scenarios in a matter suitable to it's needs. Could you please share with us what do you think should be added as a functionality? Are there any features that you find helpful and would like to be included in the following versions?
4. The reason behind this behavior is the same as the initial one and more precisely performance. If all the changes are stored and loaded this will increase the memory consumption and will make the page load slower. By design the changes are stored only on the client and are send to the server once the saveChanges method of the batch editing manager is called.
5. Next comes the documentation. We are always improving our online resources and trying to make them clean and straight-forward. That said we will highly appreciate if you can list us some points that you think might help us to achieve this. Our support officers will later review them if they find them important they will be included in the help manual.
6. The idea behind including an external framework is good but also has it's disadvantages. The main one is reliability. If there is a bug in the framework this will also break our functionality. Moreover such a framework may go through significant change and affect in different ways the implementation. That is why we have not included and external framework but rather decided to implement our own logic to handle things.
7. Last but not least comes the validation. Note that it is not triggered for the deleted row but rather for the entire form. The idea here is to alert the user that invalid data has been entered at some point(or no data is entered and should be) and corrections are needed. 

In the end I want to point out that the Batch EditMode is different in many ways compared with the rest of modes. The main difference is that it is client-oriented and allows data editing without forcing the grid to postback in order to create the edit items. This greatly improves the performance and user experience and was frequently requested by our customers. If you have any suggestions that you find important please share them with us so thus helping us on improving the product.

Regards,
Angel Petrov
Telerik

[أشرف]

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.

deleteRecord

deleteRecord method:

function (v,r){if(!this._validate(true)){return true;
}var w=this,u=b.GridTableView.isInstanceOfType(v)?v:$find(v),t,n=w._changes,p=r,m,s,q,o;
…

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.

[Angel Petrov]

Hi Ashraf,

Regarding the concrete technical solutions mentioned in points 1, 2, 4 and 7 I will forward them to our development team for review. If they prove appropriate they will be implemented in a future release.

As for the use of an external library, this decision is taken on a senior developer level. We have chosen the path of implementing our own functionality as this allows us to extend it more easily according to our needs.

Next comes the documentation. As I mentioned in my previous post we are always trying to improve our resources and are willing to add examples, descriptions and etc from which our customers can benefit. If you have a certain example that you think we should include please share it with us so we could review it.

Regards,
Angel Petrov
Telerik

[James]

Point 4 is also causing us problems and will like result in us using a different third party control.  Preserving the viewstate of the grid when other controls cause a post-back is mandatory for our scenario. 

[Angel Petrov]

Hi James,

By ViewState you probably mean the changes made by the use. Note that the ViewState of the grid is persisted and you should not experience behavior normally related to ViewState loss. Moreover I have forwarded the requests listed in this thread to our dev team for review and they are researching whether they can be implemented without affecting the performance and other functionality. If you have some specific requirement I suggest logging it in our feedback portal so it too can be listed for review.

Regards,
Angel Petrov
Telerik

[Sudhakar]

we have struggle on kendo tabstrip with kendowindow.

1. we are using kendo tabstrip control and we we load the content forms, inside content form we have some kendow window popups, but here we are able to open the window but we unable close the window.

2. using kendow tabstrip we are using kendo charts in different tabs, its not loading properly.

3. using kendo tabstrip, we have some menus, if click on menu actually open the window, but its not open the window.

4. using kendo tabstrip, kendo grid its not working multiple header columns.

 

Regard,

Sudhakar.