Filter filtering on parsedData

[JeroenNX]

Hi,

Is it possible that with the latest version the filters always filter on parsedData even though:

• th does not have filter-parsed class
• filter_useParsedData is explicitly set to false (even though it's the default)
• no headers : { 0 : { filter : 'parsed' } }
• th does not have class="{ filter: 'parsed'}"
• th does not have data-filter="parsed"

I have a custom text extraction function (for sorting) that is also being used for filtering even with the above settings; could not observe this behavior with the previous version(s).

Regards,

Jeroen

[Mottie]

Hi @JeroenNX!

It might also depend on the parser. Some parsers have a parsed: true setting (ref) which forces a column to always use parsed data.

Looking at the built-in parsers, only the "url" and "image" parsers have this flag set.

Also, it depends on the filter type. The following will use parsed data if the parser type is "numeric":

• Operators (e.g. >= 10)
• Range (e.g. 1 - 10)

It would help me troubleshoot the issue better if you could provide an example or more details.

[JeroenNX]

Hi @Mottie,

Thanks for your quick reply!
I made a minimal example on: https://jsfiddle.net/orze3jam/1/

Search in the date column for '20' => no results.
Then search for 123 => 2 results (from data-sortme).

Previously I was using version 2.19.1 with the exact same HTML/JS and with that version I was able to search for '20' or '07-2015' and get the expected results.
Same fiddle/code, only using 2.19.1 from CDN instead of latest: https://jsfiddle.net/9ap9zvqw/

P.S.: I know there's a parser for dates, just have not used it yet, and only need simple searches for now (like '07-2015' for every entry in July); could it be that the content type in a column is automatically detected and that in this case it defaults to one that uses the parsed data, and that this behavior was introduced with a recent update?

[Mottie]

Hmm, ok internally when you use a data-attribute to sort on, it uses that as the unparsed value in the filter. I'll have to do some internal fiddling to save the actual cell content as well.

Anyway, if you only added the data-sortme attribute to get the sort to work properly, you dont' really need it. The problem is that the dateFormat option defaults to mmddyyyy so the short date parser was seeing invalid dates.

Try this (demo; use 07 in the filter instead):

$(document).ready(function()
{
    $('.tablesorter').tablesorter(
    { 
        usNumberFormat: false,
        dateFormat: 'ddmmyyyy',
        widgets: ['filter']
    });
 });

If you do need the data-sortme attribute for a different reason, then you can use the textAttribute option instead of making a custom textExtraction function. The issue I stated above will be cause problems though, until I can get it fixed.

[Mottie]

Hmm, I'll have to think about this some more...

Right now if a data-attribute is used, both the parsed and raw data have the same content.

If I save the raw text from the table when a data-attribute is set, a bunch of filter widget searches fail. Because, the filter will see the data-attribute content as parsed and the raw cell content as unparsed. And most of the time it is searching unparsed content.

So, I either have to just leave everything the same, or add a filter-noparse class name that forces the filter to never search through parsed data.

What do you think @TheSin-?

[JeroenNX]

@Mottie,

Thank you for your elaborate answer.
Now that you have explained the cause of my issue I can easily work around it.

Maybe just leave everything the same and include a note in the docs for textExtraction that as of version X, if you use a data attribute in a custom textExtraction function (for sorting), the value of this attribute will also be used in filtering?