Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
thoughtafter opened this Issue · 4 comments

2 participants

thoughtafter Rob G
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.

Rob G
Owner

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

Rob G Mottie added the How To... label
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.

Rob G
Owner

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

Rob G Mottie added the Enhancement label
Rob G
Owner

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.

Rob G Mottie added the Next Update label
Rob G Mottie closed this in 26db918
Rob G Mottie removed the Next Update label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.