Proposal for new feature - In-place Grid Update

[unle70]

Hi Tony,

One idea for future development:
Currently we have the API calls for loading completely new data into the grid. We remove all the previous content and fill-in new content. This is OK for many cases.

I think it would be very nice to have an API call which can UPDATE the existing grid without removing all the records and re-filling.
Such a service should get a fresh object (JSON) with all the updated rows. It should check which rows should be removed and remove them. Then check which should be added and add them (hopefully in the correct position). Then it should go through existing rows and only update those columns which need to be changed (while applying relevant formatters). Eventually it should apply any rowAttr to the changed rows.

The application is for when a grid is used for displaying dynamic information which is updated on the far database by an external source (not by the grid user).

Currently I'm trying to do this by myself and so far it's not yet working well.
Hoping to see this as standard feature one day.

[tonytomov]

Hello Udi,

Thank you very much for the recommendation.

Maybe I understand what you mean, but I'm little confused with the description-
so, if we have set A of data in the grid and then we have new set B , as for your description
we need first to remove the records which are not in set A compared to B (suppose we work by id to do this),
then add new records which are in set B and then update existing one -
sorry, but for my understandings this is equivalent of removing set A and add set B
with one operation - correct me if I'm wrong - or I do not have correctly understand the enhancement?

Regards
Tony

[unle70]

Hi Tony,

If you consider the "functionality" only, you are right. It's exactly the same as removing all the records and then re-populating the grid with new records.

But if you start to consider PERFORMANCE and user experience when some of the columns have complex formatting, maybe some "select" fields with options loaded from the server, or anything similar which makes the data loading slow, the in-place updating starts to make sense.

In my case, maybe only one grid cell needs to be changed, which also affects the text color (Green to Red) of another nearby cell. Re-populating the entire grid for this single cell results in very bad user experience. This is why I'm making this proposal.

Thanks,
Udi

[tonytomov]

In my case, maybe only one grid cell needs to be changed, which also affects the text color (Green to Red) of another nearby cell. Re-populating the entire grid for this single cell results in very bad user experience. This is why I'm making this proposal.

In case if only one cell should be updated why do you send all rows again to the grid?
For your case Instead that one cell is changed, when you send all the rows again to the grid - how should know the grid that only one row should be updated and skip to update the other?

I think that in this case is better to create server side logic which will send only the updated rows or I have missed again something in your description.

Could you please describe in detail what is the case in detail, what is send to the grid and etc.., so that I can recommend you solution if possible?

Kind Regards,
Tony

[unle70]

Hi Tony,

The data is in a database which is updated by another application. The grid is only used as a kind of "status display". The grid is periodically pulling fresh data from the database. It is pulling ALL the data. It's not easy for the server side to analyze what exactly has changed, because that would mean the server side need to preserve "state". Currently it is "stateless".

Eventually the grid needs to (somehow) show the new situation, with the best possible user experience. This is why I was thinking to implement the change mechanism on the browser side. It requires some work, but I think it's possible.

Again, I'm not sure how many people want to use jqGrid in this way. Maybe it's only me. This is why I'm leaving it up to you to decide whether this is a good feature or not.