Best regards
Oleg

As ususal  invaluable recommendations. Now I'm going to read these more carfully and eventually ask for little help.

The first step that I should do is to reorganize and rewrite the demo.

Also I will publish the demo in GitHub. This wil hellp us a lot with recommenrdations, fixes and etc.

Thank you very much again.

I will keep you in touch

Best Regards

Tony

if you have a little time in the next two weeks it would be nice to make some small (or less small) improvements in jqGrid. I just wanted to post you some my ideas, just some subjects which are seems the mostly interesting from my point of view:

• changing error reporting in grid.inlinedit.js so that one can display exact error message from the custom validation mthod. Currently the line perpends the name of the field and one space before the text of the error message. Any solution are welcome. For example one can add new option with format like for recordtext, pgtext etc or just use no prefix in case the custom formatter.
• it would be practical to introduce common error repoting way in jqGrid. My personal favorite is the div inside of gbox or inside of gview and above of ui-jqgrid-titlebar. One can provide default implementation of loadErrorInternal or some other error callbacks which could be ovewritten by loadError etc. The callbacks could report the error by flashing the error message for 5-10 seconds above the grid (interval which could be configued or set to forever). After the interval the error div should be disapear (for example fadein/fadeout effects). In the case one can make large help for the begginer which uses jqGrid. Currently the wrong XML or JSON data or an error on the server side follows to empty grid without any error message. Showing error messages by default could be very helpful. The possibility to customize error message will stay unchanged. In the way one could provide new feature without breaking of compatibility of existing solutions. If error callback like loadError already defined no standard error reporting (loadErrorInternal) will be used. One can introduce $.jgrid.error method which displays the error message in the error div and one can use it everywhere in the code in case of error reporting. It's better as the usage of alert which block UI.
• in would be very helpful to specify validation of all input field in case of inline or form editing. Currently the validation breaks at the first error. One could build the list/array of errors for all invalid fields ({colName: "...", errorDescription: "..."}). One can mark all the fields with "ui-state-error" class and set focus on the first field with error (see the answer for an example). One can add title (tooltip) with error description on the corresponding field with error.
• introduction of any way to provide custom formatter and some custom additional properties (like cellattr, formatoptions etc) for predefined columns ("subgrid", "rn", "cb"). It could be enough to have the possibility to apply $.extend(true, ...) with the corresponding properties. One can just include one-tree lines of code to make it possible. Alternatively (or additionally) one could incroduce one callback which will be called at the end of initializing part of jqGrid: after calling of populate() in the line. The callback could be practical for many common customizations.

If you have interest to improve performance of jqGrid I could suggest some ways which I see for it:

• the most simple and effective way to improve performace in many cases is making of upades of the DOM elemens on temporary disconnected grid or parts of grid. Look at the example of the function removeToInsertLater from the article. One can use the aproach in many cases where multiple changes needed be done. In my tests methods emptyRows or clearGridData can took a lot of time in case of reloading of large grid. Another example is the method showHideCol called for large grid and many columns. If one need to hide or to show multiple columns the action will be currently done not as one operation on the HTML document. So many browser reflow will be made. Temporary removing of the whole grid from the page and reinserting it back after all actions will be done can improve the performance of the modifications in many times.
• I wrote you before about performance improvement by generating of closure function which build cell, row and so on. If the column has no formatter and no cellattr at all for example the building of the cell of the column could be done by calling of the simplest closure which body contains only
  val ? String(val) : ""

   or if autoencode: true is used then

  val ? $.jgrid.htmlEncode(val): ""

  (the code of every from the closure is even more simple as the body of cellVal method). NO ADDITIONAL CODE WILL BE EXECUTED. All tests of parameters of colModel will be done once at the beginning of addJSONData or addXmlData. So the actions made in the loop will be short and quick. In the current implementation common code of formatCol, formatter, cellVal, addCell will be executed every time if the cell for the column will be added in the new row. Instead of that one could analyse the opetion of the every column of colModel once and generate closure for exery column. The complaxity of the closure will depend from the complexity of properties used. The only problem is that relativly many changes of the code of grid.base.js need be done. The function addJSONData, addXmlData, formatCol, formatter, cellVal, addCell, addMulti, addRowNum need be full rewritten. The advantage will be the best possible performance which is really attractive. I have codes of such changes based on more old version of jqGrid. It works very good.

There are a lot of other ways of further development of jqGrid which I see, but I don't wanted to post too long text here.

Best regards
Oleg 

Thanks again for the recommendation.

The demo is really very very old - (the client and server parts should be tottaly rewriten.

I have some time this and next week, so any ideas on how to organize change and design are welcome.

Kind Regards

Tony

The demo "Search Templates" found under "Searching" will be shown in the tree part of the demo only in Google Chrome. IE and Firefox don't shows the demo at all. Clicking on the text "Search Templates" in the tree node don't open any demo.

One more remark. It would be nice to reorganize the tree part of the demo based on the features provided by jqGrid. The parts like "New since beta 3.0", "New in version 3.1" abd so on are difficult for the visitors.

One more remark. I see from regelmassig example of code copied from "Loading Data" / "Array Data". The demo was made for very old version of jqGrid in the time when no local data was supported. Moreover the for-loop of the demo contain wrong expression i<=mydata.length instead of i<mydata.length. The demos which use addRowData should be reduced in my opinion and the option gridview: true should be added in practically every demo.

Best regards
Oleg