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

[thoughtafter]

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]

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").

[thoughtafter]

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]

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

[Mottie]

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.