data-sorter="false" should bypass parser detection loop #629

thoughtafter opened this Issue May 27, 2014 · 4 comments


None yet
2 participants

data-sorter=false should bypass the detection loop. In big tables this loop is a performance issue. I think the problem code is here (only cursory examination):

Line 242 jquery.tablesorter.js

p = ts.getParserById( ts.getData(h, ch, 'sorter') );
// empty cells behaviour - keeping emptyToBottom for backwards compatibility
c.empties[i] = ts.getData(h, ch, 'empty') || c.emptyTo || (c.emptyToBottom ? 'bottom' : 'top' );
// text strings behaviour in numerical sorts
c.strings[i] = ts.getData(h, ch, 'string') || c.stringTo || 'max';
if (!p) {
    p = detectParserForColumn(table, rows, -1, i);

If data-sorter=false p is false which then calls detectParserForColumn. If data-sorter is deliberately set to false this loop should be skipped because the user is asking for no sorting.


Mottie commented May 27, 2014

Hi @thoughtafter!

The parser type is still detected because in some cases a filter widget will need parsed data from a non-sortable column. For example, this would be true for dates within a column which need to be parsed in order to properly apply operators like >, >=, < and <=.

The parser detection code shared above is only executed at table initialization and when an update is triggered ("addRows", "update", "updateAll" and "updateCache").

Mottie added the How To... label May 27, 2014

Thank you for the prompt reply.

It my current use cases, for all columns with data-sorter=false I also have data-filter=false. So this request could be changed to: avoid detectParserForColumn if both of these conditions are in place. Or, alternatively if some other mechanism could be used to skip the detection that would be fine too. Thank you.


Mottie commented May 28, 2014

Sure, I could add this sort of enhancement. Let me do a little testing to make sure it won't cause any problems.

Mottie added the Enhancement label May 28, 2014


Mottie commented May 28, 2014

It makes sense that the code within the core shouldn't be written to make exceptions for widgets. So, the solution I came up with was to add a new parser-false setting. It can be added as follows:

  • A data-attribute (data-parser="false")
  • metadata (class="{ parser: "false" }")
  • A header option (headers : { 0 : { parser: "false" } })
  • or, as a class name to the header (class="parser-false")

This change is now available in the working branch; and I do plan on pushing out the next update by this weekend.

Mottie added the Next Update label May 28, 2014

Mottie closed this in 26db918 May 29, 2014

Mottie removed the Next Update label Jun 19, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment