I have an editable igGrid set up to save pending transactions using RESTful services. Excerpt:
$("#ar_invoices").igGrid({ aggregateTransactions : true, columns : [ blah blah ], features : [ { name : 'Updating', editMode: "row", showDoneCancelButtons : true, columnSettings : [ blah blah ] } ], restSettings: { contentType: "application/x-www-form-urlencoded; charset=UTF-8", contentSerializer: iggridUrlEncode, create: { url: env_constants.DATASERVICES_URL + "/ar_invoices/" }, update: { url: env_constants.DATASERVICES_URL + "/ar_invoices/" }, remove: { url: env_constants.DATASERVICES_URL + "/ar_invoices/" } } });
The issue I'm currently wrestling with is error handling when a batch of changes are submitted. Here is my JavaScript function for saving pending changes:
function ar_invoice_changes_save() { $("#saveResult").text(""); $("#ar_invoices").igGrid("saveChanges", function (data) { $("#user_prompt").text("Changes were saved successfully").fadeIn(3000).fadeOut(5000); }, function (jqXHR, textStatus, errorThrown) { alert(jqXHR.responseText); });}
My question is how to handle errors if the user adds multiple rows and saves them. The grid seems to keep all pendingTransactions around, which makes sense if they are saved in a transaction, but RESTful transactions are submitted independently. For example, consider the following scenario:
This is not a problem for PUT, which is idempotent, and possibly not for DELETE, but POST-ing new rows is explicitly not idempotent.
At a high level, my options seem to be:
Does the grid have any support for #1? For example, knowing which pending transactions succeeded, if any? (Note: I am using "aggregateTransactions : true" so as I understand it, each edited row is effectively one transaction.)
Other suggestions also welcome. Thanks,
I thought of another workaround, possibly the most logical one, which would be to bypass the grid's saveChanges logic completely and do it myself. I would need to:
i) iterate over pendingTransactions ii) serialize the correct HTTP transaction depending on whether the row was added, edited, or deletediii) clear the pending transaction for each successful transaction
The controller method OrderSaveData from the Basic Editing Sample (http://www.igniteui.com/grid/basic-editing) does some of this, except of course its written in ASP.NET, not JS. And I don't see any code for step iii, which would be needed prevent the problem I mentioned with duplicate POSTs.
Please consider this approach along with my previously suggested approach. Again, I'm looking for suggestions how best to work around my issue, whether it is one of the ones I came up with or some other approach. Thanks.
Hello Matthew,
I am attaching a sample that you could try using as a basis for implementing a custom save procedure.
You are right that the error handling is not ideal in the case of REST updates. We have had this improvement pending implementation in our backlog for a long time and your issues with it should increase its priority. I am sorry again that we do not provide the best out-of-the-box support for your case and you need to use so many workarounds.
If you have any questions about the sample or need help expanding it to work for your project, please let me know!
Best regards,
Stamen Stoychev
Thanks. This looks promising; I'll let you know how it goes.
FWIW I don't see anything wrong with requiring the programmer to write row-by-row logic in some cases. (For example, I might want to do that if the RESTful operation assigns a new key to the row. I could refresh the row's data without rereading the entire grid.) But the necessary code shouldn't be too low-level. In your sample, the modified-record CSS class needs to be removed manually, and there is a call to an underscore function _removeTransactionByTransactionId. I think it just needs sanctioned, higher-level operations to accomplish the same things.
Of course I wouldn't complain if Infragistics came up with a more automatic approach. :-)
The _removeTransactionByTransactionId function provides some automation. You should be able to achieve the same if you implement a function that removes a transaction by id from the transaction arrays obtained with the pendingTransactions and allTransactions methods. It's not exposed as public because technically you wouldn't have needed it if the default error handling had been better.
I hope you were able to move on with your application!
I got this solution mostly working; clearly it's a viable solution to our problem. Thanks!
The main challenge now is that our service assigns a new ID after a POST; we'll need to update the row accordingly. In addition the service defaults some fields if they were not filled in by the user. (This isn't strictly RESTful behavior, mind you.) So we'd have to read back the updated data and update that row. (Or move the defaulting logic into the web page so that the call is truly RESTful.) We'll have to muddle through these issues, but at least the approach seems sound.
Thanks again.