I am trying to set up an igGrid to do CRUD via REST. I have two questions, either one of which might be enough to get us unstuck.
1. We bind the query results (JSON array) to the grid, as follows:
$.ajax({ type : 'GET', url : BASE_URL + '/ar_invoices', data : params, dataType : 'json', success : function(invoiceRows) { $("#ar_invoices").igGrid("option", "dataSource", invoiceRows); }, });
This works well for display. However, when I add the "Updating" feature and restSettings to the grid, things don't work. Not only does the grid not send any updates to the server, but the grid behavior is wrong:
So the first question is: can restSettings be used if the dataSource is NOT a URL, but is instead a JSON array? Every REST example I've seen uses a URL dataSource so I'm thinking that might be part of our problem.
2. To try and answer question #1 I tried to set our dataSource to the URL instead:
var url = BASE_URL + '/ar_invoices'; $("#ar_invoices").igGrid("option", "dataSource", url);
The GET request sent by the grid includes Accept = "*/*" in the header. Unfortunately the service supports both JSON and XML using the same URL. It relies on the Accept header to determine what format to send back, but defaults to XML. So we'd need the grid to explicitly request JSON in the header(*). Is there a way to customize the headers it sends?
(*) Note that the XML feed isn't working: igGrid is throwing a parse error. But as igGrid seems to prefer JSON (and so do we) we don't want to spend any time on the XML issue if we can help it.
FWIW we'd prefer the approach in #1, as this gives us full control of the Ajax query. (We might need that to work around CORS issues, for example.) So if there's nothing inherently wrong with that approach then I'll probably have to post a followup message with more details.
Thanks for any assistance,
Matt
Hello Matthew,
I am glad you were able to progress on your project.
You are right that Updating has some limitations when using Virtualization. You can find more about these in our Known Issues list.
As for the exception, either the specific configuration or some code of yours is trying to change the data view of the grid while there still are transactions (edits) not yet committed to the local data source. While the exception suggests two ways to avoid this completely, it will still be worthwhile to find the exact culprit. If you able to provide me with your grid's configuration and event handlers I could also take a look.
Best regards,
Stamen Stoychev
> we provide some customization on the ajax request, such as request type and contentType
Thanks for the pointer. (FWIW I find the name responseContentType somewhat misleading, as it only controls the format of how the request is sent, not the server's response. And the corresponding restSettings option is simply "contentType".)
I'd suggest adding a new option corresponding to the jQuery ajax.dataType parameter. But as I said before, we aren't planning to use this approach so don't prioritize this feature on our account.
> I assume the Updating issues are caused by something else and you could check the browser's console for any exceptions that could give you a hint.
There were no console exceptions before today; but after some edits I am getting some (details below).
Thanks for the sample code-- very helpful. I've made some progress by trying to make my code look more like the sample. My findings so far:
• A big one: there was a typo in the jQuery expression preceding my call to saveChanges. So the breakpoint was hit, but no grid was found so no call made. • If I remove the virtualization=true and virtualizationMode="continuous" then the editing behavior improves: edited values don't disappear, and the row is italicized properly. Plus, with virtualization=true I now see a useful error in the console after an edit: "Error: Grid has pending transactions which may affect rendering of data. To prevent exception, application may enable "autoCommit" option of igGrid, or it should process "dataDirty" event of igGridUpdating and return false." So I'm guessing this is known behavior, and that mixing virtualization with editing requires extra work. (Our workaround: turn off virtualization.)
I'm not out of the woods yet:
• No matter what I set restSettings{contentType: ...} to, the request headers contain Content-Type = "text/plain". However, I AM able to change the Content-Type in your sample project. So I'm trying to isolate this. • Add New Row is still not working properly on my live page, even with virtualization turned off. But I have gotten it working in a toy version of that page, so I'm hopeful I'll find the cause soon.
I'll post back if I need more assistance, or discover something interesting. Thanks for the help so far!
You should be able to bind the grid in the way you show in p. 1. I tried it with a small WebAPI/REST sample on my side and it works correctly. I assume the Updating issues are caused by something else and you could check the browser's console for any exceptions that could give you a hint. In any case I am attaching my sample which will hopefully save you some time.
As for the issues with the second approach, we provide some customization on the ajax request, such as request type and contentType, however, we can certainly expand on it with more options. Binding to XML should also be working, and the binding error is likely caused by some misconfiguration that I could research on if you could provide me with a small sample that reproduces it.
Thank you for using Infragistics forums! Please, let me know if you have any other questions or concerns!