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
Hi Matthew,
We can continue the discussion about the content type in the other thread.
As for virtualization, after some pondering I think it may not be possible to support continuous virtualization with Updating and autoCommit false anyway due to some restrictions in the rendering routine. We'll make sure this is clearly stated in the Known Issues list with the next documentation update.
To summarize the solutions, either of these will work
- enabling autoCommit
- using fixed row/column virtualization
- skipping virtualization entirely in favor of the igGridPaging feature.
Please, let me know if you have any other questions or concerns!
Best regards,
Stamen Stoychev
Stamen,
Thanks for tracking that down! We'd have no problem updating to 15.2 if necessary, but for this particular application we are fine with keeping virtualization turned off.
Looking back over all the issues we discussed above, only one which hasn't been resolved along the way:
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.
I've isolated this: the only one actually failing is Remove. New & Update are working fine. I can reproduce it in your sample project. I have started a new forum thread for that issue.
Thanks for your help figuring out all my bugs (plus the one grid bug :-)
Sincerely,
Hello Matthew,
Now that I tested it again having continuous virtualization mode and auto committing disabled does throw this error when editing. I must have tried it with fixed virtualization or something else was wrong with my sample to prevent me from noticing it in the first place. Further digging confirmed my suspicion that Updating tries to rerender the grid when a row is updated with continuous virtualization enabled. This is done to prevent some other issues from happening but actually breaks the update when auto commit is disabled.
We are working on improvements for the Updating feature for 15.2 and the virtualization support is one thing that will most definitely receive updates, however, I am not sure we'll be able to apply them for the previous versions. For your project I can suggest either enabling autoCommit or not using continuous virtualization. Other ways of limiting the number of displayed rows and increasing performance are the paging feature and fixed virtualization.
Please, let me know if you have and other questions or concerns!
That does help. Stamen. I got that dataBind call from some other forum post, but I guess that wasn't a scenario where the user was editing.
Note that I only added the revert button recently. I thought it was exposing the same problem that you originally asked me about on 7/16. I'm glad to fix the Revert button but it's not clear to me if there is another problem. You seemed to be saying that virtualization alone wouldn't account for that exception happening earlier. If I learn anything else I'll post a followup.
Thank you for the sample! Calling dataBind would trigger rendering of the grid's body. Since there are pending (uncommitted) changes, the grid tries to prevent the loss of data in the form of the user input and throws an exception instead.
Actually, there is an API with the purpose to revert changes - rollback . You could use it for your revert function like this:
$("#ar_invoices").igGrid("rollback", null, true);
Which would rollback all transactions and update the UI (but without rendering the whole grid anew).