Should one replace the usage addJSONData of jqGrid to the usage of setGridParam(), and trigger('reloadGrid')?

Question

I wrote recently an answer to the question "jqGrid display default “loading” message when updating a table / on custom update". While writing the answer I thought: why does he use the addJSONData() function for refreshing data in the grid instead of changing the URL with respect to setGridParam() and refreshing jqGrid data with respect to trigger('reloadGrid')? At the beginning I wanted to recommend using 'reloadGrid', but after thinking about this I understood that I am not quite sure what the best way is. At least, I can't explain in two sentences why I prefer the second way. So I decided that it could be an interesting subject of a discussion.

So to be exact: We have a typical situation. We have a web page with at least one jqGrid and some other controls like combo-boxes (selects), checkboxes etc. which give the user possibilities to change the scope on information displayed in a jqGrid. Typically we define some event handler like jQuery("#selector").change(myRefresh).keyup(myKeyRefresh) and we need to reload the jqGrid container based on user's choices.

After reading and analyzing the information from additional user's input we can refresh the jqGrid container in at least two ways:

1. Make call of $.ajax() manual and then inside of success or complete handle of $.ajax call jQuery.parseJSON() (or eval) and then call addJSONData function of jqGrid. I found a lot of examples on stackoverflow.com which use addJSONData.
2. Update url of jqGrid based on user's input, reset current page number to 1 and optionally change the caption of the grid. All these can be done with respect to setGridParam(), and optionally setCaption() jqGrid methods. At the end call the grid's trigger('reloadGrid') function. To construct the url, by the way I use mostly jQuery.param function to be sure, that I have all url parameters packed correctly with respect to encodeURIComponent.

I'd like us to discuss the advantages and disadvantages of both ways. I currently use the second way, so I'll start with advantages of this one.

One can say: I call existing Web Service, convert received data to the jqGrid format and call addJSONData. This is the reason why I use addJSONData method!

OK, I'll choose another way. jqGrid can make a call on the Web Service directly and fill results inside the grid. There are a lot of jqGrid options, which allow you to customize this process.

First of all, one can delete or rename any standard parameter sent to the server with respect to the prmNames option of jqGrid or add any more additional parameters with respect to the postData option (see http://www.trirand.com/jqgridwiki/doku.php?id=wiki:options). One can modify all constructed parameters immediately before jqGrid makes the corresponding $.ajax request by defining of the serializeGridData() function (one more option of jqGrid). More than that, one can change every $.ajax parameter by setting the ajaxGridOptions option of jqGrid. I use ajaxGridOptions: {contentType: "application/json"} for example as a general setting of $.jgrid.defaults. The ajaxGridOptions option is very powerful. With respect to the ajaxGridOptions option one can redefine any parameter of $.ajax request sending by jqGrid, like error, complete and beforeSend events. I see potentially interesting to define dataFilter event to be able to make any modification of the row data returned from the server.

One more argument for the use of the trigger('reloadGrid') way is blocking of jqGrid during the AJAX request processing. Mostly I use the parameter loadui: 'block' to block jqGrid during JSON request sending to the server. With respect to jQuery blockUI plugin http://malsup.com/jquery/block/ one can block more parts of web page as the grid only. To do this one can call:

jQuery('#main').block({ message: '<h1>Die Daten werden vom Server geladen...</h1>' });

before calling the trigger('reloadGrid') method and jQuery('#main').unblock() inside the loadComplete and loadError functions. The loadui option could be set to 'disable' in this case.

And my last remark: Mostly I used to create jqGrid with the datatype set to 'local' instead of 'json' and I would call the trigger('change') function of some of the controls (one of the comboboxes) like: jQuery("#selector").change(myRefresh).keyup(myKeyRefresh).trigger('change'). Thus I construct the url parameter of jqGrid only in one place inside of the change handle and change datatype to 'json' inside the above described setGridParam().

So I don’t see why the function addJSONData() should be ever used.

Can somebody who uses addJSONData() function explain to me the advantages of its usage?

To be fair I can add that addJSONData() which exists in older versions of jqGrid as having most of the features which I describe here. Should one replace the usage of addJSONData of jqGrid to the usage of setGridParam(), and trigger('reloadGrid')?

Answer 1

I've been using addJSONData with jqgrid, but it was 1 year ago, a lot of things have change since that time in jqGrid.

Anyway, I needed heavy & complex gui manipulation on the client side (bank share things), my Json data was local only and sent to the server as some jkey point (job finished). I had several jqgrid (some of them inside others jqgrids :-) ) and some sort of local browser storage of data which was small enough to stay in the browser and complex and moving enough to be unusable in a reasonnable time via ajax IO.

First version were using Ajax IO, when I've been hit by the locks and wait problems and by the amount of new complex GUI things coming I've been really happy to find this addJSONData hook and have my own ajax timeline outside of jQgrid.

Answer 2

Ease of building of grid / data from a server. One of the main reasons i use JSON, is that its smaller then XML, and works well on both the server (PHP) and client (JS) side. And as a result, i standardized (and i know several do) data transmission in between to JSON.

Hence, addJSONData provides an easy way out to constantly update all the data in the grid, and display it in one shot. Its quick, fast, dirty, and it works.

However personally, this will turnout to be a bad idea over the long run, with large datagrid constantly refreshing. And thats where, updates to specific cell / columns, after the initial get, is a much better idea to have 2 calls. Submit grid change to server, and get changes from server.

So one of the main advantages of doing this, is that its a fast start. And when the data gets too big, the add all option downgrades to only occur once at the start. While individual update / gets can be added, after the initial data grab.

Its a good work cycle : Fast prototype -> Effective client-server datagrid