Inline edit: Server response for one field only

blcdhq

I am currently stuck trying to adapt the inline editor trial version for my purposes. I am building a response object according to this page: https://editor.datatables.net/manual/server, but the difference is that the row data only contains the changed field, not all the fields.

This means that my json response object does not contain data for all the columns in the row, but only for the edited column. But this does not seem to be acceptable to Editor, because it will delete all the column data for the row.

Is it correct that even for inline editing of one cell, Datatables needs a response object which contains all cells (fields) for the row?

As it is impossible for me to return the whole row data from the server (I am using the inline editing for a different purpose with a custom backend), I would like to be able to only update the cell (column) which I have edited with the response data, and not touch the other columns in the row.

Is there a workaround for this scenario? Maybe I could use the postSubmit callback to construct a json object from the existing row data and update only the changed column with my server data.

How would I access the row with the edited column in the postSubmit callback? The response data does contain the row_id, but how do I get the table cell data.

Or maybe there is a different, better way?

Thank you

allan

the difference is that the row data only contains the changed field, not all the fields.

This can be controlled by the submit option of the form-options object. You can use all or allIfChanged for example. You can configure that in formOptions.inline or inline() (among others).

Regardless of the data submitted, the server much always return the whole row. This is because other fields might be calculated (for example an update time). I might change that in future to allow only some fields to be returned, but for the moment all are needed.

Regards,
Allan

blcdhq

OK, thank you for the clarification. I will manipulate the response row data in postSubmit to create a row with all data.

seth9009

Hi Allan,

u said that in the future this may change (the need to send the entire row as json) has this changed ? the reason i'm asking is because i have a HTML generated datatables (not json response) with inline editor and i have a checkbox at the first column then a drag sort (that is not managed by editor) action links as last column .. so no DB content and they are set as not editable, in the mean time has there been added a way to just skip them and render just the changed cell ?

allan

With 1.6, no, this hasn't changed. You still need to have the server return the whole row of data.

Having said that, 1.6 does now have a local table editing option (example) which doesn't require Ajax. Although obviously you'd need to use something to make the changes permanent.

Allan

seth9009

this looks interesting, is there a callback when a change is made that i can use so i can do my custom ajax post on server ? i don't see any in the documentation .. so i'm assuming not .. worth asking ..

on another note i've done this by reading the TR row before the ajax call to server, and on server i simply sliced and diced the data and post it back the only change being the updated cell .. hope it helps someone ..

allan

The events would be used for that. edit for example might be useful in this case.

Allan

anthonys

Not requiring the whole row server response would be great. In some cases other fields are calculated from the changed cell, but in many (indeed most?) they are not, or may be calculated client side with rowCallback functions. How about datatables assumes there is no change to the data unless the server responds otherwise? The server just responds with the changed fields, if any.

This means that no read request is required by the back end to return the data. This has two advantages:
A read request could take longer than you think!
There might be significant resource associated with generating the row response. It could be a simple database read, but in other applications the database may be encrypted and fields may have a lot of display related post-processing. Many CMS's have a lot of overhead just to wake them up and may have all sorts of database abstraction and display layers. If you're making a lot of edits in an inline editing context this can lead to a slow UI and in my experience bugs caused by the user making one edit before another is finished, which can also lead to server sync issues.

We can queue requests
Even if a read request is fast we still have to wait for the server response before updating the row and allowing a user to perform another action. By not requiring a read request we could queue up requests client side and then send them to the server using a parallel process. This would make use of the local table editing option and is something I might look at implementing. For now though, server responses would have to be 'faked' to datatables, effectively handing it back its own data for the unchanged fields. Looking at editable web apps like Gmail, Trello and the like, although they do have very fast node.js (and perhaps MongoDB) server stacks they also allow server update requests to be queued up. However fast the back end is, the user might still be on a laggy internet connection.

Anthony

allan

Thanks for the feedback. A queuing mechanism is something that will be coming to future versions of Editor.

One important consideration with that however will be data validation. At the moment Editor focuses almost entirely on data validation at the server-side, since it has to be done there anyway. With client-side queuing it becomes more interesting - validate for each item (which means client-side validation as well as server-side), or validate all together when submitted, which would annoy the user.

Quite a lot to consider for this.

Allan

anthonys

I might have posted a little too soon! I've just upgraded to recently released Editor 1.6 and the ability to use localstorage and write a custom ajax submit function is awesome! Barring the validation issue, or the occurrence of an error, it alleviates the need for a substantive server response at all. I don't think it should be too hard to queue up ajax requests and have a little "Communicating to server" icon appear while they are ongoing. If there's a communication error then the user could be alerted and asked to refresh the page, perhaps being presented with a list of edits that couldn't be saved.

I see your point about validation. It's hard to know how to deal with that. For some applications it is a problem, others not. It depends on the type of data submitted. The server can still filter/reject malicious requests and for applications like checkboxes, multiselects and free text fields there isn't always too much front end validation required.

Thanks so much for Editor 1.6!

Anthony