Wildcard filter behavior

[glend1]

Hi,

I have a Tablesorter Jquery object on a webpage, I have managed to get it working as I intend. There is, however, a small issue. Wildcard filters do not seem to work logically. After removing the other filter types (using the method described here; http://mottie.github.io/tablesorter/docs/example-widget-filter-custom-search.html) to ensure none were conflicting. I then filter using the phrase "test" and all other "test1", "test2" and "test3" results match, this is not logical behavior because when I filter "test|something" I loose test1/test2/test3 results.

I tested with and without exact filter types but the exact type doesn't trigger unless you include a = or ".

Using UI conventions I agree with with the way it is automatically detected and currently done. Perhaps you could allow "text" filter type to be turned off/deleted and include a partial match type with a higher priority than wild.

As a temporary work around I force regex. /^text$|^text$|^text$/i

[Mottie]

Hi @doveyg!

The wildcard filter is set up to exactly match content when you use a logical "OR", so using test|test 1 will only find test and test1, and nothing else (like test10).

If you want the wildcard to match content, then add a "filter-match" class name to the header (demo).

Hopefully that makes everything work as you would expect.

[glend1]

I don't see any behavioral changes. when you type "test" without the quotes nothing is removed, as apposed to showing just 1 match, "test".

[Mottie]

Maybe adding a second table to the demo will clarify things?

[glend1]

I see. The issue I see is that on either table if you enter exactly "test", without the quotation marks. then it goes into Match mode. It would seem that the class is ignored until you put "|" in.

[Mottie]

Huh? When I type in "test", it matches all content with "test" in both tables. It's when you type in "test|" that it appears to exactly match "test" in both tables, until you start typing something else, e.g. "test|a".

[glend1]

It's not strange to you that when you go from "test" to "test|" to "test|abcd" you get 9-1-2 records using exact? or "t" to "t|" to "t|a" you get 9-0-10 records using match?

In my option, "t|" should count as "t" on filter match. While "test" should count as "test|" using filter exact.

[Mottie]

Hmm, you're right, that should be changed. I'll see what I can do after I finish working on these other updates ;)

[glend1]

Side note. Which are the most efficient/fastest filter types? I imagine; wild is one of the slowest, exact the fastest and regex somewhere in between.

[Mottie]

Please try the update available in the working branch. Here is an updated demo using that change.

[glend1]

still behaviors strangely imo. typing "test" into exact returns 9 results. typing "test|" into exact returns 10 results. i would expect a single result for both.

[Mottie]

The "exact" part only applies when you are using the "or" operator.

If you want to always get exact results, either define a filter function:

filter_functions: {
  // Exact match only
  0 : function(e, n, f, i) {
    return e === f;
  }
}

or set a default filter:

filter_defaultFilter : {
  0 : '{q}='
}

But as I said before, I keep an open mind about making changes. Anyone else, like @TheSin- or @thezoggy, want to chime in here?