Develop Reference

OnDemandGrid with dstore Tackable and Memory not showing complete data when data is set into it

I have OnDemandGrid with dstore Trackable and Memory store associated with it. Initially, a memory store with empty array is set. When actual data is fetched and set into the grid, grid does not display full data. It always displays 100 rows.
Moreover, if any column is sorted, then it displays entire set of data.
Grid is created in following manner
this.grid = new (declare([Grid, Selection, ColumnHider,ColumnResizer,Keyboard, Selector]))({
// use Infinity so that all data is available in the grid
//className: "dgrid-autoheight",
showHeader: true,
collection: self.memStore,
minRowsPerPage : 100,
bufferRows: 10,
pagingDelay : 15,
farOffRemoval : 2000,
columns: modifiedColumnList,
selectionMode: "extended",
//pagingLinks: true,
//pagingTextBox: true,
//firstLastArrows: true,
//rowsPerPage: 100,
//pageSizeOptions: [100, 150, 250],
adjustLastColumn : true,
loadingMessage: 'Loading data...',
noDataMessage: 'No data.',
allowSelect: function(row){
return true;
},
keepScrollPosition: true
},this.domNode);
Memory store is created in following manner
var TrackableMemoryStore = (declare([Memory, Trackable]));
Data is set in the following manner
self.memStore = new TrackableMemoryStore({ data: gridData, idProperty: "SRVC_ORDER_ID",defaultNewToStart : true });
self.grid.set("collection", self.memStore);

This sounds like an issue identified in dgrid 0.4.1 and 1.0.0, which happens if you call startup on your grid before it is actually displayed.
In most cases, this is something that should be fixed in your own code, since startup should only be called after the grid's element is in document flow. However, Dijit's StackContainer also happens to call startup on all of its children before they are really displayed, but typically gets away with it because it then calls resize when they're actually displayed.
There is a fix for this issue on the master, dev-1.0, and dev-0.4 branches, so if you use the latest commits from one of them, this should be resolved.
(Incidentally, in earlier versions, the grid would simply end up requesting all data from the store at once, which is definitely not a good thing for large or server-based stores.)

free-jqgrid: easier way to save, load and apply filter data including filter-toolbar text and page-settings?

I have a pretty standard jqGrid using free-jqGrid 4.13 with loadonce: true;
What I want to do is something I came across a couple of times:
I want to save the state of the grid (without the data);
that means the settings (number of current page for example), filters the user applied and also the text in the filter-toolbar.
and then load and apply this data to the grid later.
jqGrid is such a powerful tool, but stuff like this seems such a pain to accomplish.
after hours and hours of work i came up with a complicated solution; it is working, but it's not a nice solution imho:
1) saving jqGrid filter-data (locally):
// in this example i am using the "window unload" event,
// because i want the filters to be saved once you leave the page:
$(window).on("unload", function(){
// i have to access the colModel in order to get the names of my columns
// which i need to get the values of the filter-toolbar textboxes later:
var col_arr = $("#list").jqGrid("getGridParam", "colModel");
// my own array to save the toolbar data:
var toolbar_search_array = [];
for(var i = 0, max = col_arr.length; i < max; i++)
{
// only saving the data when colModel's "search" is set to true
// and value of the filterToolbar textbox got a length
// the ID of the filterToolbar text-input is "gs_" + colModel.name
if(col_arr[i].search && $("#gs_" + col_arr[i].name).val().length)
{
toolbar_search_array.push({ name: col_arr[i].name, value: $("#gs_" + col_arr[i].name).val() });
}
}
// putting everything into one object
var pref = {
// 1. toolbar filter data - used to fill out the text-inputs accordingly
toolbar : toolbar_search_array,
// 2. postData - contains data for the actual filtering
post : $("#list").jqGrid("getGridParam", "postData"),
// 3. settings - this data is also included in postData - but doesn't get applied
// when using 'setGridParam'
sortname: $('#list').jqGrid('getGridParam', 'sortname'),
sortorder: $('#list').jqGrid('getGridParam', 'sortorder'),
page: $('#list').jqGrid('getGridParam', 'page'),
rowNum: $('#list').jqGrid('getGridParam', 'rowNum')
};
//saving in localStorage
localStorage.setItem("list", JSON.stringify( pref ));
});
2) loading and applying jqGrid filter-data:
for use in a document-ready closure, for example
var localsave = JSON.parse(localStorage.getItem("list"));
// these settings are also saved in postData,
// but they don't get applied to the grid when setting the postData:
$('#list').jqGrid('setGridParam', {
sortname: localsave.sortname,
sortorder: localsave.sortorder,
page: localsave.page,
rowNum: localsave.rowNum
});
// this applies the filtering itself and reloads the grid.
// it's important that you don't forget the "search : true" part:
$("#list").jqGrid("setGridParam", {
search : true,
postData : localsave.post
}).trigger("reloadGrid");
// this is loading the text into the filterToolbar
// from the array of objects i created:
console.log(localsave.toolbar);
for(i = 0, max = localsave.toolbar.length; i < max; i++)
{
$("#gs_" + localsave.toolbar[i].name).val( localsave.toolbar[i].value );
}
it seems strange to me that postData contains all the data necessary but it's impossible to apply this data; at least as far as i know.
my question(s):
is it really this inconvenient to apply all the filter- and paging-data or am i missing something?
why can't this be as simple as:
// saving:
var my_save = $("#list").jqGrid("getGridParam", "postData");
// loading:
$("#list").jqGrid("setGridParam", {
search : true,
postData : my_save
}).trigger("reloadGrid");
?
thank you for any help and/or suggestions!

The answer with the demo provides an example of the implementation. The method refreshSerchingToolbar is relatively long. On the other side the code is still not full. It's not restore the state of operands, if the option searchOperators: true is used. I wanted to rewrite many parts of the filterToolbar method to make easier the saving/restoring of the the state of the filter toolbar or refreshing based on the changed postData. It's just the problem of the time and nothing more. What you describe is close to the feature forceClientSorting: true, which was difficult to implement in original code of jqGrid 4.7, but it was easy to implement after I rewrote large part of processing of the server response. The same problem is with the code of filterToolbar. The changes of filterToolbar is still in my TODO list and I'll made the corresponding changes soon.

Initial handsontable view does not stretch to correct width

I have a handsontable object (in fact two objects, both in a bootstrap modal) that have data loaded after the page is built. Here's a jsfiddle that duplicates the problem https://jsfiddle.net/mtbdeano/w7dofbyy/
The tables are sized way too narrow, even given the stretchH: all option. Once I click in the content, they resize like magic to the correct column width. Am I missing some initialization parameter? How can I have it size to the correct width after loading new data?
/* these tables are in the modal */
$('#keyword_table').handsontable({
data: keyword_data,
rowHeaders: true,
colHeaders: ['Keywords'],
columnSorting: true,
contextMenu: true,
height: 256,
stretchH: "last",
enterBeginsEditing: false,
minSpareRows: 1
});
I am loading the data using this code which is called on a successful ajax call:
function load_table_from_ajax(tbl, data) {
var $tbl = $(tbl);
var hot = $tbl.handsontable('getInstance');
// this formats my data appropriately
var new_data = _.map(data, function (kw) {
return new Array(kw);
});
hot.loadData(new_data);
/* I have tried also doing a: hot.render(); */
}
All the code looks correct as per tutorials, any idea why the table doesn't stretch/resize correctly?
Before interacting with the Handsontable, it looks like this:
but after clicking the header or adding a value:

Try giving a width on initialization. Since you're not setting it, the stretchH might be having trouble doing the calculations it needs. I've seen that behavior before and setting this usually fixes it.

try colWidths:[100]
Defines column widths in pixels. Accepts number, string (that will be converted to number),
array of numbers (if you want to define column width separately for each column) or a
function (if you want to set column width dynamically on each render).

jqGrid colModel persists to server but trigger reloadGrid fails to put data in right columns

Question in a nutshell
With each column tweak, I save the new column model to the server, for that user, and immediately start mutating the JSON to align with the new column order for that user's ajax requests. In this scenario, do I still need the remapColumns function or the permuatation variable?
My initial jQGrid (4.4.5) is loaded using datatype:'json', loadonce:true (fwiw)
The server explicitly writes out the javascript variables to properly initialize the grid's colNames and colModel in the desired order, width and desired 'hidden-ness' - unique to that users' last saved settings (if any). For example:
var MainTableColumnNames = ['Work Order','DatePickedUp','Generator','Order Status'];
var MainTableColumnModel = [
{name: 'Work Order', index: 'Work Order', editable:false, align: 'left', hidden:false, width:82 },
{name: 'DatePickedUp', index: 'DatePickedUp', editable:false, align: 'left', hidden:false, formatter:'date', width:120 },
{name: 'Generator', index: 'Generator', editable:false, align: 'left', hidden:false, width:264 }, width:293 },
{name: 'Order Status', index: 'Order Status', editable:false, align: 'left', hidden:false, width:50 }
];
I have my own method for saving col model data to the server and am not using any of the concepts that I've run across recently (it seems Oleg has addressed this a lot). FWIW: I only save width,size,hidden (and the column layout order is implied). Thus, some of the above col model is supplied from user settings, while other parts are derived from defaults or by reflecting on properties of the .NET System.Data.DataColumn
Furthermore, the resizeStop event and the extended column chooser both point to a common script function which persists changes in the column layout. Thus, the next time the user loads the web page, everything will be laid out according to the new settings saved for that user. That is all working fine.
But.. even before they reload the web page, any new requests to the server will now be sending the json data back to the user in the new column order. And, I am not sure what is going wrong. The column sorting issue that I've seen others refer to elsewhere on StackOverflow is not happening to me.. you can click a column header and the data re-sorts in place (I presume it is because I use loadonce, so it sorts using existing localdata).
But, if I click on a node in my tree control (i have my own tree implementation that loads various slices of data into the main grid) the new JSON data coming back is not successfully loading into jqGrid- a couple of columns look transposed -
Now if I do a full page refresh everything is fine.
An example of how I get new data into the grid, say, when we click one of my tree nodes:
$('#myCustomTreeNode').bind('tree.click', function(event){
var node = event.node;
var newUrl = '/api/DataView/MainGrid/' + node.id;
$grid.jqGrid('setGridParam',{url : newUrl, datatype: 'json', postData: { 'guid':someVariable} }).trigger('reloadGrid');
});
Update: So here's my question:
So, my main question is: after updating a jqGrid column model (not only jqGrid's client model, but when the successive server-supplied data will immediately conform to the new column order).. I want to know the proper way to continue using the current instantiated jqGrid instance w/o a full page re-draw. Must I do a full GridUnload or GridDestroy? I'm hoping someone can give me pointers on something I must be doing wrong with my .trigger 'reloadGrid' call illustrated above.
More detail
As stated in my opening paragraph, each user has their own "MainTableColumnModel" variable written to their browser session.. literally on page draw, the physical column order is written in the order of their last saved column permutation.
And, I think this is where I am possibly getting things wrong.
In other examples like this one by Oleg it seems all users should be getting the same initial column model, and if they've saved a specific model into their user settings, then I should be loading up that as a permutation variable for remapColumns to process when the page intially loads, rather than transforming all the JSON data requests according to each users' individual column-model setting.
Since I've got my alternate method almost working, I'm still hoping I can get this right.

KendoUI Grid Server Dynamic Column binding in service callback

I am trying to understand the working of KendoUI Grid. I have successfully returned paged data from the server and server side paging is also working.
But I am having problem with setting column details dynamically i.e. neither the titles show up nor the template, the column header shows the name of bound field. I think the problem is related to when columns are initialized because I get to know about the details of columns after call back from the service.
Here is how I am binding the grid:
$("#kGrid").kendoGrid({
dataSource: {
serverPaging: true,
schema: {
data: "data",
total: "total"
},
pageSize: 10,
transport: {
read: function(options) {
var searchParam = new Model.SearchParamsCM('QuoteDomainTasks', 'QuoteList', false, options.data.page, options.data.pageSize);
seHttpService.GetWithParms('/spa/api/genericrequest', searchParam)
.then(function (result) {
var data = oThis.createJSONFromResults(result.data, oThis);
options.success(data);
},
function(result) {
options.error(result);
});
}
}
},
columns: oThis._gridColumns,
scrollable: false,
pageable: { "refresh": true, "pageSizes": true },
sortable: true,
filterable: true
});
Where oThis._gridColumns is populated inside oThis.createJSONFromResults. This code is in TypeScript.

The data source is only for reading the content of the grid, not its configuration (which only needs to be created once, when setting up the grid). You need to separate these two concerns so that oThis._gridColumns has the column definition when you call $("#kGrid").kendoGrid().
Dynamically changing the column definitions is not really supported by Kendo Grid, so if you need that, your options are:
recreate the whole grid whenever the column definition has to change
change things manually (e.g. if only titles change, you could do that by selecting and editing the elements with jQuery)
try to mess with the internals, e.g. something like the following
(note this is largely untested and might break with new Kendo UI releases)
grid.options.columns = changedColumnDefinition;
grid.table.find(">thead").empty();
grid._columns(grid.options.columns);
grid._thead();