aaSorting based on th-class

aaSorting based on th-class

StrayerStrayer Posts: 2Questions: 0Answers: 0
edited March 2012 in Feature requests
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.


  • StrayerStrayer Posts: 2Questions: 0Answers: 0
    This is also confusing for the user if the columns change because the sorted field is saved as an integer index in the cookie.


    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
  • tomas_eklundtomas_eklund Posts: 14Questions: 1Answers: 0
    Agreed! I came here today just to make the same request so I'll just chip in on yours. While I do love DataTables and appreciate all the effort being put into it, this feature (being able to control initial sorting by class name) is so fundamental that I'm frankly a tad bit baffled that it's not already implemented.

    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.
  • george9eggeorge9eg Posts: 6Questions: 0Answers: 0
    I concur. However, given that class names are not necessarily unique, an ID might be advisable - or perhaps even a jQuery-like #id or .class selector syntax. Indeed, the mechanism(s) provided for specifying the column by other-than-index should be extended consistently across the API (in addition to those provided by mDataProp elsewhere) to make it straightforward to specify sorting/filtering/whatever by identifying *what* is in a column we're interested in rather than the ambiguous notion of *where* it happens to be (especially given plug-ins that allow the user to hide and reorder things on us).
  • allanallan Posts: 51,045Questions: 1Answers: 7,665 Site admin
    I've got three stages to my answers for this thread - bare with me while I built it up :-)

    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?

This discussion has been closed.