aaSorting based on th-class
aaSorting based on th-class
![Strayer](https://secure.gravatar.com/avatar/9af499c03c4ff1feae5f4e5f404c6c4d/?default=https%3A%2F%2Fvanillicon.com%2F9af499c03c4ff1feae5f4e5f404c6c4d_200.png&rating=g&size=120)
It would be great if I could specify the column index in the aaSorting-array as the class name, more or less like in the aoColumnDefs-array:
[['th_class_name', asc], ...]
The current design makes it impossible for me to define an initial sorting because the html is dynamically created while the javascript is a static file - so column indexes change.
[['th_class_name', asc], ...]
The current design makes it impossible for me to define an initial sorting because the html is dynamically created while the javascript is a static file - so column indexes change.
This discussion has been closed.
Replies
Example:
Last time the user visited:
id | name | created_timestamp[sorted]
Current table with new column:
id | name | address | created_timestamp
Next time the user visits:
id | name | address[sorted because of integer index] | create_timestamp
Initial sorting based on class name can be fixed with a few lines of added JavaScript, but I guess that the state saving problem you mention would need a lot more work to fix. Either way, I feel that this should be a core feature, and not something you'd need a plug-in for.
1. Immediate fix:
Defining an initial sort column with a class and a touch of jQuery is easily enough done. For example: http://live.datatables.net/awunaw/edit#javascript,html
2. Plug-in fix:
One thing that I've fancied doing for while a while with DataTables is to create a plug-in that would scan the HTML for the table and build a DataTables initialisation object out of what it finds. You could define sType, etc for columns and so on. I've just not had the time to implement that yet I'm afraid. Also I don't believe that this would belong int he core - it would add considerable weight to DataTables, which I'm not willing to do! It would need to be an option plug-in :-)
3. API update:
> Indeed, the mechanism(s) provided for specifying the column by other-than-index should be extended consistently across the API
Yes a hundred times over! This I would very much like to do for DataTables 1.10, along with a couple of other API modifications (they should all be backwards compatible).
I'd be interested on some feedback on this, if anyone would like to chip in: the way I was thinking about implementing this was using the sName parameter. With sName you can "name" each column, and uniquely identify it as such - when wherever in the API you want to access that column (column filtering for example) you could use that name rather than the index.
The big disadvantage with that is this is that if you want to benefit from this, then you must specify sName, which I absolutely do not want to be mandatory. In fairness it wouldn't be - you would only be required to specify sName if you wanted to benefit from the newer API access options.
What do you all think?
Allan