Can I change default filter criteria operator from "iContainsPattern" to "iContains"?

[christoferjennings]

Is there a way to change the default filter criteria operator from "iContainsPattern" to "iContains"?

I'm getting empty values included when filtering a field on the word "undefined" or any sub-string of "undefined".

Every datasource field that is of type:text and that has empty values in the database gets unexpected results showing empty values. It happens when filtering on the word "undefined" or any sub-string of "undefined". The best hypothesis so far is that the empty value from the database is translated to the javascript 'undefined' identifier. And when the comparison is done, undefined is coerced to the string "undefined", which is then compared case-insensitive using a 'contains' method. This could happen if the value is concatenated with a string because javascript: "" + undefined === "undefined"
I haven't been able to reproduce the problem with the Smart GWT showcase. It uses HSQL while we use PostgreSQL but I doubt that matters. Also, though, the showcase doesn't have any empty values to begin with. I used the ISC Admin Console to remove values, but that might just be inserting empty strings (wild guess).

The Smart GWT filter defaults to "contains pattern". This problem doesn't happen if I use "contains" (by filtering with the filter expression symbol ~).

Thanks!
-Chris

SmartClient Version: v11.0p_2016-08-09/Enterprise Deployment (built 2016-08-09)
FireFox 24 (because we're using dev-mode)

[Isomorphic]

It looks like you're trying to switch away from a useful default because of the speculation of a bug. If you can instead provide server logs for the request that has bad behavior, or a way to reproduce it, we could either fix the bug or tell you what's wrong with your usage.

As far as switching the default operator, enabling allowFilterExpressions is what switches the default operator to iContainsPattern. It's currently only possible to switch it back on a field-by-field basis via listGridField.operator. Another possibility would be to use allowFilterOperators, which similarly allows users to choose operators for filtering, but provides a menu-driven approach so users do not need to know the prefixes for operators to use them.

[christoferjennings]

Sorry, but there aren't any server logs. This all happens in the client. One thing you could try is creating a datasource that uses PostgreSQL and put sparse data in text fields.

I'll try the listGridField.operator approach.

Thanks for the tip!
-Chris

[Isomorphic]

OK, if you think it's a problem just with client filtering, that's fine, but we still need a way to reproduce it.

We already have automated tests showing that iContainsPattern behaves as expected, including undefined and null data, so there's no need to set up a further test to try out your hypothesis. Most likely, this issue is created by an idiosyncrasy of your data, which you would discover in the process of trying to make a test case where other people could see the problem.

[christoferjennings]

That very well may be.
Might you be able to share your tests? Then I could try it on our setup.

[Isomorphic]

No, they are automated tests dependent upon an automated test environment with many services.

But you can also very easily use the Showcase samples to see that the containsPattern operator doesn't have weird issues with null values.

[Isomorphic]

Note that we've added a new attribute, ListGrid.defaultFilterOperator - you can set that to apply a custom default operator to applicable fields in a grid's filterEditor. The change will hit builds dated April 26 and later.

[christoferjennings]

Thanks for the update. Hopefully we can upgrade to the latest version soon.

I did verify that I can't reproduce the issue in showcase before my first post, by the way. But I can't control it enough to be confident it's relevant to our setup. It would be nice if there were tests that we could use to see if we're doing the same thing, same complexity of configuration etc. All I can see is that the results are different and that our code does nothing to intervene in the filter process. ... At least until I get that infinite-time gadget I've been dreaming of. ;)

[Isomorphic]

The Debugging overview in the docs gives helpful advice for quickly preparing test cases from existing apps. You don't actually want a second starting point that has complexity similar to your app, as the whole point is to rapidly eliminate possible causes.