Changing DT_RowId in the preSubmit event not working

jladbury

I am working client-side only and want to update the id set in the DOM when adding a row.

My preSubmit code:

    editor.on('preSubmit', function (e, data, action) {
        if (action !== 'remove') {
            data.data[0]['DT_RowId'] = '55';
            return c9dataTable_evValidate(this);
        }
    });

Regardless of the value I set DT_RowId to ('55' above), the DOM is updated to tr id="0" ...

I have raised this as a bug, but am prepared to be told I am doing something wrong!

jladbury

I have tried to create a suitable JSBIN, but every time I add the Buttons library I get a script error. My latest attempt is at live.datatables.net/dekecagu/3/edit

allan

Yes, this isn't an expected interaction. Why would you want to change the row id in preSubmit? Surely that risks data corruption since the row already has its row id to uniquely identify it?

Allan

jladbury

My app maintains an array of chronological events, each with a unique id. For example:

{
"id":"1",
"startDate":"25 Dec 1950",
"startTime":"00:00",
"endDate":"22 May 1952" 
...
}

On dataset load, I set the DOM id to the event id like this:

function c9createTableData(): [any] {
    c9.appVar.tableData = c9.appVar.document.chronology.events.map(function (ev) {
        return {...ev, ...{'DT_RowId': ev.id}};
    });
    return c9.appVar.tableData;
}

with the table being defined as

    $.extend(c9.appVar.$table['DataTable'].defaults,
        {
            'dom': '<"c9tableTools01"Bf><"c9tableBody"t><"c9tableTools02"lipr>',
                'data': c9createTableData(),

When I add a new event with Editor, I want to assign the next free id in the dataset.
I keep the id's in the dataset in sync with the DOM id's for ease of access by DOM id. The process works fine on loading data, but I cam across the problem when adding an event with Editor. I hope that's clear - let me know if not, and I will load the latest version of my app to my test web site so you can poke around a bit more!

There's a bit more background in https://datatables.net/forums/discussion/58167

Having said all that, the doc for preSubmit here does say it can be used to set the DOM id ... hence why I raised as a bug.

allan

Thanks for the explanation! I wonder if you need to set the id property rather than DT_RowId since your data set appears to use id.

For example here I use idSrc and rowId to point Editor and DataTables to the DOM id, and the preSubmit needs to reflect that.

Allan

jladbury

Thanks Allan. I have some good news and some bad!

The first good news is that, following your bin, I was able to remove a lot of redundant code in my app that was maintaining separate arrays for my dataset and for DataTables. This old code came about because I had not fully understood that DataTables did not actually need a DT_RowId specified if you specified rowId in the initialisation parms.

The bad news is that, having tidied up the code by adding idSrc and rowId as per your bin, and thus allowing DataTables to interact directly with my dataset, the problem still remained.

The second bit of good news is that my problem goes away if I specify ONLY rowID and not idSrc.

However, I am reluctant to implement this for now as it runs counter to your recommendation. And indeed, if I update your bin to remove idSrc, I just get a hang when trying to add a new record - see my updated bin.

I hope you agree that something 'fishy' is going on and will look into this further. The only obvious difference between the bins and my app is that the latter is loading code from a JavaScript object; might that be relevant?

I have a Word doc with some more info showing Chrome debug stuff regarding how my app runs with and without idSrc. Happy to send it to you if you think it might help.

jladbury

Allan,
A quick answer to the following (possibly stupid) question might help:

When I specify the data initialisation option as an array of JSON objects, does this mean that DataTables will automatically update the data array whenever Editor updates the table? That is, data does not only intialise the table, but maintains it when Editor change are made.

I ask because I suspect that there might be a conflict between some of my code, that directly updates the array, and what DataTables is doing.

allan

Adding idSrc set to be id is still the right thing to do I believe, since that tells Editor where you have your id property.

The data.data[0]['id'] = '55'; in your code isn't doing anything since you don't have an id field in your Editor field list. So that code (on create) is adding an id property, but that's then being effectively ignored. You could use a hidden field if you wanted to be able to set the id programmatically but not allow the end user to set it.

Also on edit note that the data.data indexes are based on the primary key value - so it would be data.data['55'].id = newId.

Allan

jladbury

Hi Allan,

I have re-instated both rowId and idSrc, and added a hidden field to Editor as you suggest, but still have the problem.

I am a bit puzzled about the need for the id field in the Editor field list, as your bin does not have one but works fine.

I would like to get to the bottom of this sooner rather than later. What is your availability if I were to purchase a Support 60 package?

jladbury

Lordy lordy, having just produced another load of diagnostics and saved them for your possible persual, I thought to update Editor et al to the latest version using the excellently simple means of visiting the specified URL.

The problem has gone away!

Just one thing now that I notice - the DataTables debugger still says there is a new version of DataTables available, but when I try the download again (using the new URL) I am delivered the same package. I have uploaded the debugger output (Upload complete - ozehej) .

And, in case it is of interest, I have updated the debugger package for the levels giving me the problem - (Upload complete - arecus)

allan

Just one thing now that I notice - the DataTables debugger still says there is a new version of DataTables available,

Ignore that for now. 1.10.18 and 1.10.19 are software identical. It was a packaging error for npm that required .19 to be released.

.20 (soon) will bring them into sync.

Allan