Hello,
We are using a remote data source with igGrid (Infragistics version 2013.2) in an ASP.NET application.
The behavior we are after is that when the user enters a filter value that doesn't exist in the grid, our server web method (that the grid automatically calls on remote sorting) will return an empty row set (but a full column set) so that the grid can still keep its auto generated columns but have no rows. Currently we are building the JSON string on the server and pushing it back to the client via HTTP response. How would the JSON string need to look in order to bind the columns but no rows in igGrid?
Since our data sets are user generated and we cannot know what columns will be included until runtime we are using autogeneratecolumns : true in igGrid.
An example of our JSON with rows:
{"totalRowCount":1,"data": [{"ColA" : "A"}, {"ColB" : "B"} ]}
How do we return that JSON if it had 0 rows?
Please let me know the progress of this work around and if I could be of further assistance.
Why wouldn't I want to persist the state of filtering, sorting etc? If I didn't then every time a user filtered, sorted or switched page in the grid all other filters/sorts/page info would wipe, even though the user is viewing the same grid. He/she doesn't care if we bind the entire data set to the grid and do local sorting/filtering/paging or if we only bind small subsets and handle those events remotely. The user experience should be the same which means as long as the user stays on that grid the controls should be persisted, just as they would if we were using local sort/filter/paging. Since we are using remote filtering/sorting/paging we get a new subset of the entire data source from the server on each user interaction, which is the point with begin able to handle these events remote.
I guess I will have to find a workaround for this myself, though as stated it is strange that your grid supports remote filtering/sorting/paging but doesn't support the data set returned to contain 0 rows (that behavior is supported when those operations are handled locally afterall).
Hello Johan,
I am glad you received the required information using our forum.
In case destroying the grid is not an option for you, using dummy data in order to display the grid columns seems the course to take. Although, why would you like to persist the state of filtering, sorting and paging while the dataSource is changed eludes me, since these are for the context of the old one.
Just for reference, here is an online sample illustrating the use of remote igGrid Remote Paging, Sorting, and Filtering, you may find useful:
http://www.igniteui.com/grid/aspnet-mvc-helper
Hi,
Destroying the grid is exactly the kind of behavior we are trying to move away from since it introduces a lot of issues with persisting the state of filter, sort and paging along with introducing the need for us to programmatically add logic around all grid interactions. So it is not an option to go back to that. Given the help in this thread (http://ko.infragistics.com/community/forums/t/90338.aspx) we are almost at the finish line with our new implementation, we only need to be able to return an 0-row data set (with column definitions) from our server side web method. As an example of a workaround (that's ugly though) you can return a fake data set with the real columns but with only one row consisting of only the empty string. It will mean the grid behaves as we want it to, but of course having that empty single row just to get the grid to display doesn't feel like an option.
Since your grid supports remote actions such as filtering it doesn't seem that impossible that it should be able to handle what happens when the filtering returns the empty set, and not just crash..
This is a very specific scenario indeed. In order to change the dataSource in this particular scenario, I suggest it could be done by destroying the igGrid and creating a new one, using a new instance of $.ig.DataSource.
The thing is that if you change the igGrid dataSource, the grid still persists its data Schema. So let’s say you have a 2 JSON looking like :
var namedData = new Array();namedData[0] = { "ProductID": "1", "UnitsInStock": "100", "ProductDescription": "Laptop", "UnitPrice": "$ 1000" };namedData[1] = { "ProductID": "2", "UnitsInStock": "15", "ProductDescription": "Hamburger", "UnitPrice": "$ 10" };
var namedData2 = new Array();namedData2[0] = { "ProductID1": "1", "UnitsInStock2": "100", "ProductDescription": "Laptop", "UnitPrice": "$ 1000" };namedData2[1] = { "ProductID1": "2", "UnitsInStock2": "15", "ProductDescription": "Hamburger", "UnitPrice": "$ 10" };
Note the difference is in the “Key” part of the Key: Value pairs for the first two elements ProductID and UnitsInStock.
Initially set namedData as dataSource for the igGrid and render the grid...
var ds= new $.ig.DataSource( { dataSource: namedData2 } ..then change the dataSource to namedData2..this will result in rendering only the last couple of columns. As the first two no longer match the igGrid schema, they will be rendered empty. This is when using autoGenerateColumns: true.
Using option like $('#table1').igGrid('option', 'dataSource', ds) is also not an alternative, as the result expected is the same as above.
This is why it could be required to destroy the igGrid in order to generate the correct schema, when re-instantiating it with the new dataSource. Please refer to the codeAttachment for details.