Inline editing in datatables

devians

Im managing some new features in a legacy application utilising datatables. This makes for some odd architectural choices, so forgive some of the following code smells.

We need inline whole row editing. This is generally fine on dom loaded tables. On ajax tables it gets a little tricker, but i've managed to solve most behavioural issues like losing changes from the server update when updating a row etc.

My general model for managing datatables is to grab the data using the underscore function, manipulate it, and update the table, then perhaps grab the row via dollar and manipulate some dom cosmetics. I keep the data as clean as possible, and utilise some closure magic with mDataProp in order to provide special rendered views like cells with a tags, currency views, percentages etc.

I have been playing with two different models for turning on the form for the current row:
1. Manipulate the dom directly on edit, load values from the dom into an object and use fnUpdate to update the data and rerender the row.
2. Overload mDataProp to be super smart and allow it to render form widgets when the data has the property of edit = true, otherwise render normally. Works fine except for stomping other field changes etc. just a huge state handling mess really.

My current issue, is that I have certain widget types that pull in complex information, or multiple datapoints. IE an autocomplete field which pulls in 2 strings and a few id's to manage.

I cant populate these extra datapoints into the datatable store immediately, as if i use fnUpdate, even with rendering turned off, it hits mDataProp again to rerender each col, killing my form or mangling my state. (hence solution 2, but its problematic in terms of state handling user changes vs the data store).

At the moment i'm thinking my only sane course of action is to store the complex data points as an object and use mDataProp to render them properly, and then pull them apart at various points to get the relevant data. I'd have to do this by storing metadata against the dom and then pulling that on the row save to put back into the datatable store for the row. Kludgy.

I suppose in the end I'm just trying to say that im annoyed that datatables is so heavily coupled when it comes to data source and rendering, and I'm looking for ways to keep my data source clean while the rendering does all kinds of tricks. Finally, I can provide specific code examples if necessary but its kind of a huge pile and i dont want to overload you immediately.

allan

How are you using mDataProp at the moment? If you use it as a function ( http://datatables.net/blog/Orthogonal_data ) the rendered data can be completely decoupled from whatever you need for the rest of the control - however, from your description, I'm guessing that you are already using it as a function?

What does the data that you are using for each cell look like? With mDataProp you could readily use an object for every cell, a property of which is what will be displayed and everything else can be used for whatever you need to provide your editing controls.

Allan

devians

I am using mDataProp as a function. The architecture is somewhat like this:

I have 2 actions, Edit, and Update.

on Edit:
get data from datatables
get the dom for the row
figure out the correct widget for each cell
manip dom to replace cell contents with widget with current data as values.

on Update:
grab dom for row
read out all form values
grab current data from datatables
merge datasets
call fnUpdate.

In this case, fnUpdate restores the row to what it should be with the new data.

My problem arises when one cell stores multiple points of data. I suppose what i'll have to do is have a pile of hidden form elements to store this information to read back out again.

my alternate method had mDataProp changing rendering modes to either edit (form) or non edit (normal data render). which works but has its own issues.

allan

> My problem arises when one cell stores multiple points of data.

So am I right in saying that multiple editing widgets would be shown for that single cell? Does your data source object hold the multiple data points for that single cell (it could be an array of data points for example)?

Allan

devians

that single cell would have an autocomplete in it, which would return say, a human readable name and an identifier which is the actual value for the cell.

I ended up storing each complex datapoint in my data source as an object, and setting up my code to handle that, ie how to render out the widget + extra hidden fields to track, then later save to the appropriate place etc. works ok :)

allan

Yup - that sounds like a sensible approach to me :-) Good to hear you got it going.

Allan