Degradation in functionality since 1.6.2 version ?

lambder

Hi,

In version 1.6.2 I was able return arbitrary objects in fnServerData (as call to the callback) and then access these objects by fnRowCallback function in order to set these objects to TR element of the table (using $.data) (and with help of hidden columns). I was using this for storing info needed for TR click listeners.
In version 1.7.5 this is not possible as all fields returned in fnServerData are converted to a string in _fnAddData:2543.

Is there a 'more' correct way of achieving the same result in 1.7.5 ? If not, are there any plans to bring the old functionality back and let the appropriate fnRender to convert the object values to strings?

--
Cheers,
Daniel

http://vanadiumjs.com


P.S. Many thanks for a great plugin.

allan

Hi Daniel,

You are quite right that this was possible in 1.6 (an unintended 'feature' though!) but now not in 1.7 due to the casting of the parameters that was introduced. I can certainly see the advantage of what you are looking for, and would like to integrate support for exactly this in future - at the moment attaching an object to a table column feels like a bit of a hack to me, since table columns should really contain display objects only. Of course if you are aware of this limitation and hide the column, then it can be quite useful as you are seeing.

To allow 1.7.x to do what you are looking for you can change this block:

[code]
if ( typeof aData[i] != 'string' )
{
aData[i] += "";
}
aData[i] = $.trim(aData[i]);
[/code]
to

[code]
if ( typeof aData[i] != 'object' )
{
if ( typeof aData[i] != 'string' )
{
aData[i] += "";
}
aData[i] = $.trim(aData[i]);
}
[/code]
I'm a little reluctant to include this in the DataTables source at the moment, because as I say I don't really like this method and would hope to replace it with something which is planned in the next major release - so this would only be a temporary solution that would work in the next few minor releases only. As such I don't want to introduce a 'feature' that I know I will break in future - although authors such as yourself who are aware of this issue might want to proceed with the above modification anyway.

Does that sound reasonable? :-)

Thanks for flagging this up thought! It's certainly something I want to address.

Regards,
Allan

lambder

Hi Allan,

Thanks for your answer. That is what I thought from bref look at the code. Anyway I second that mixing logic with presentation is not good idea. Although keeping the model in the table object (not table DOM element may be quite useful and appropriate as well) Attaching object to TR was just an example of what was possible, it can be done much more with the access to the raw object and not to pollute DOM at the same time. Anyway what I was more up to was the idea of keeping model as it is returned from server side (or deconstructed model into per column sub models) and let renderers do the rest, every time the String value is needed (cached/memoized of course for performance reasons). So functionally it would be the same but the rendered would be used on demand not pre populated. That would open the possibility of changing the columns renderers dynamically without the need for table recreation. Personally I'd go further and keep the whole row object internally. Such row object could have reference to current table row and page and do deferred rendering in background (you can imagine the usage such as loading images when rows are in view or asynchronous row detail fetch by custom ajax).

I wish I have time to contribute to data tables plugin, but need to finish my vanadium2 as I promised the community ;). Once more big thanks for a great job and good luck.
--
Regards,
Daniel

allan

I like the idea of keeping the same object returned from the server - I didn't at all like the idea of casting the data as a string, since it meet I was effectively modifying the data set into DataTables - nasty. However, I liked the idea of not doing it even less :-). Leaving the original object untouched but providing DataTables with a way to read data out of it and into it's internal array sounds ideal.

I'm going to target 1.8 with this feature.

Regards,
Allan