Best Method to Programmatically Set Values to Save as well as update UI

Boilermakers

This is a general question regarding best practices when trying to save values and submit them to the backend. I see many different options and scenarios and am generally able to do what I need to do. There is one scenario that is unfortunately not working.

I popup a custom form for data entry and upon closing the form using the close event, I want to run a series of queries to gather data and populate 6 columns from the same row programmatically. I want tp save the data immediately, but also updating form fields to display to the user.

I can reliably retrieve the row data;

var rowData = table.row(modifier).data();

Now the question: What is the best way to both save an update to the rowData and to update the UI.

Option 1:

rowData.field1 = 'new value1';
rowData.field2 = 'new value2';
rowData.field3 = 'new value3';
rowData.field4 = 'new value4';

editor.edit(rowData,false).submit();

Note: this does not always work.

Option 2:

editor
.set('field1','new value1')
.set('field2','new value2')
.set('field3','new value3')
.set('field4','new value4')
.submit();
or do I use
.val or .field.val.

Other options?

I've tried both independently, and together and I get inconsistent saves. When trying to save to the database, I can see that the updated values are not passed to the server-side.

I'm not asking for troubleshooting at the moment, just a clear answer on how I should do this and make sure I have all of the required steps.

Thanks

colin

This example from this thread may help - it's capitalising the surname before submitting to the server by modifying the data being sent.

Could you look at that, please, and see if it helps. If it's still not working for you, please can you update my example, or link to your page, so that we can see the problem.

Cheers,

Colin

Boilermakers

Thanks for your example. What I am seeing in my example, I inserted a preSubmit event and logged the object being submitted, the object contained all rows in the table. Not the specific changes I made.

What is confusing is that in other parts of my code, I can submit the exact same code, and only the columns/rows I changed are being submitted.

It looks to me that this submit is basically submitted an older cached version of all the data. I can submit a test case, but I suspect I won't be able to recreate it.

I'm asking for help with this pattern and possible causes.

Thanks

allan

If you want to just programmatically set values and submit data, then your option 2 is almost the correct way to do it. You are missing triggering an edit or create action. For example if you want to create a new row based on the given values, call create():

editor
  .create(false) // don't show
  .set('field1','new value1')
  .set('field2','new value2')
  .set('field3','new value3')
  .set('field4','new value4')
  .submit();

Likewise if you want to edit an existing row, then you need to use edit() to tell it which row you want to edit.

Allan

Boilermakers

I've been able to find the right combination to update as expected. But, this did NOT work when chaining. What is the difference when chaining?

Thanks for your help.

// Worked
editor.edit("#" + rowId, false)
editor.set('field1','new value1')
editor.set('field2','new value2')
editor.set('field3','new value3')
editor.set('field4','new value4')
editor.submit();

// DID NOT WORK
editor
.edit("#" + rowId, false)
.set('field1','new value1')
.set('field2','new value2')
.set('field3','new value3')
.set('field4','new value4')
.submit();

colin

Odd, they both should be that same - as edit() and set() both return an DataTables.Editor instance. The benefit of chaining is that it just shortens your code, that's all, so if it works without, then that's still fine.

Colin

Boilermakers

Agreed. But I just did that one switch and it worked. I will try to provide a good test case to show my results. I am using custom forms and onClose events.

Thanks for your quick response.

allan

Agreed, there should be zero difference between those two pieces of code. If you were using variables for the values and one of them was undefined then it would break with the chaining approach. But that's all I can think of.

Allan

Boilermakers

I discovered a sneaky asynchronous issue when trying to reuse a function. This does not have to do with chaining. The chaining / not chaining in my testing resulted in slightly different timing that allowed another function to finish. In a speedy environment, that small difference gave different results. The code was submitting twice, the first time with the new data and the second time with an instance of the data prior to being changed. This overwrote the "new" data with the old data (blanks) appearing as if the submit was not working.

Thanks again.