aTargets and mData column names

SteveJ

I've got a table which uses mData to set the names of the columns for pulling the data from the json stream:

[code]
{ "mData": "id", "aTargets": [0] },
{ "mData": "name", "aTargets": [1] },
...
[/code]

This works great. There are a number of other things I'm doing in with "aoColumnDefs", including setting visibility, mRenders, sortables, etc... For each of those other items, I still need to refer to the data items by position, i.e. with "aTargets[0]". I can't use the TH for this column in particular since I'm using a checkbox for the column heading. Also, for other columns, I'd rather not use the TH, since the TH doesn't always match the column name. i.e. TH could be "System Name" and the column name within the data could just be "name".

Is there any way to use the column names from within the data for aTargets? I'd like to be able to re-order the columns without needing to go back through and check all of the aTargets.

Thanks!

-steve j

allan

Yeah - the column indexes can be a bit of a pain. What you can do currently is use a string for the target ( `aTargets: [ 'hello']` for example) which will match any column which has the class 'hello' in its column header cell. That allows columns to be address, individually or as a group, by name, which can be useful.

Is that what you are looking for?

Allan

SteveJ

It's not optimal, because I need to define the column names in two places. It will work, though. I'll go with that for now.

thanks!

-steve j

SteveJ

Allan - I've been thinking about this one. Would it make sense for dataTables to be able to define table headers themselves? The more I use the server side processing and the mData structure, the less I want to define using HTML. I now have my back end written so that it doesn't need to know the field names for queries - it pulls them from mDataProp. If you could extend dataTables so that the column headers and classes are set from within the dataTables definition, that could become the sole authoritative source for table metadata. I can see things getting to the point where all you need in html is a tag with an ID set and everything else comes from dataTables. Do you think that's a good direction?

As a side note, would there be any interest in a generic Perl back-end for server side processing that relies on mDataProp and that uses DBIx::Class for the database interaction? My code has a ton of customization beyond that, but I think it would be a cool exercise to pull out the generic parts into a separate module.

thanks!

-steve j

mstew

I agree with Steve that it's nice to have it not care what columns you have rendering. I have mine being created in JavaScript right now but then I have to do all of the creation of my headers and transformations from the way my data is formatted into the format DataTables needs too, and that is giving me some problems :(

allan

Agreed. The new API in DataTables 1.10 is going to make a lot more use of the column names given by sName (or `name` as it will be in 1.10 :-) ).

Allan