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,
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!
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!
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!
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,
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).