Adding filter on caretChange, and new TextParserOperands

[GoogleCodeExporter]

What steps will reproduce the problem?

TableFilter api is awesome, but lacks some features for particular applications
1. Sometimes, it is handy the filter to be applied as user types it (at each 
keystroke). 
2. The parser operands lack a feature where the row value starts with the 
filter, or contains the filter. It can be done using a regexp, but the user may 
not know anything about regular expressions.

What is the expected output? What do you see instead?

* The code included in this issue provides those two new features as the 
setFilterOnKeyChange methods, throughout the code, and new operators, ~s and ~c 
for "startsWith" and "contains" operands. Feel free to use the code as is, or 
to do a better implementation of these new features. The code is based on 
version 3.1.2 of the api

What version of the product are you using? On what operating system?

3.1.2

Please provide any additional information below.

just patch version 3.1.2 with the included patch file, or replace the files 
with provided files if you want to include this feature in future release. The 
compatibility with 3.1.2 is preserved, those features are only activated if 
used.

Original issue reported on code.google.com by fabien.n...@gmail.com on 26 Oct 2010 at 2:44

Attachments:

• patch.zip

[GoogleCodeExporter]

Hi, Fabien,

again, sorry for the very late reply.

The first option that you propose would be quite expensive to implement (on 
performance) on the new library's version (have a look to the implementation 
done for adaptive options). Nevertheless, could be toggled on/off in the 
API.... I will check how bad can be the performance....

For the parser, I think I understand now better your other issue with 
setDefaultOperator. In the current implementation, it is not needed to use 
regular expressions; for example, to select all rows starting with 'Fan' it 
would be enough to write 'Fan*' [which is, I think, more intuitive than writing 
'-s Fan']

This applies to all types. For example, on a column with integers, writing '4*' 
returns all rows starting with '4', even if the user didn't specify the 
operator '~'
That is, the implementation uses the operator '=' or '~' as it is best suited.

I will study the patch now, again, sorry for the late reply,

Best regards,

  Lu.

Original comment by coderazzi on 16 Feb 2011 at 7:06

• Changed state: Accepted

[GoogleCodeExporter]

Hi, Fabien,

I checked your patch, thanks for submitting it. I have reimplemented it for the 
4.0 version, not when the caret is updated but when the text itself changes, 
and the performance is not bad at all. Of course, it depends on the number of 
rows in the table.
But the UI must be more advanced. In this moment, to write 'Fan' you will 
obviously start as 'F', then 'Fa', then 'Fan', but in the intermediate steps, 
the table would filter out all the rows! ('F' is not 'F*'). I guess it is a 
matter of interpreting 'F' as 'F*', etc, but then what happen if the user just 
want to have 'F'?
Any suggestions are welcome, I will be thinking how to better introduce it (the 
behavior is rather cool!)

Best regards,

  Lu.

Original comment by coderazzi on 18 Feb 2011 at 1:28

[GoogleCodeExporter]

Hi Lu,

Thanks for checking my modification, I can tell you that users are very 
impressed with the result... 

I implemented a generic table, merging TableFilter with JXTable, which permits 
the user to totaly customize the filter using the "ControlButton" feature of 
jxtables (see attachment). I think this class could be added in a swingx 
utility library as a generic option, if I make it even more generic. I will 
submit it later. It may be interesting to implement a "FilterControlButton" 
that can be integrated directly in the top right scrollpane area, but not tied 
to swingx implementation. I will eventually invest some time in both solutions, 
and submit the code.

Concerning th "F" or "F*" thing, I think it is totaly tied to what the 
programmer wants. I think it makes sense to activate the "AutoUpdate" feature 
only in two case:
* the programmer set the default filter to "Start with (~s)" or "Contains (~c)" 
* the user is aware of behaviour (he has to enter the * if the filter is ~)

Again, since it is a feature that can be disabled, the programmer will be free 
to do whatever suits the users...

Best regards,

Fabien

Original comment by fabien.n...@gmail.com on 18 Feb 2011 at 1:51

Attachments:

• jxtable_tablefilter_control.png

[GoogleCodeExporter]

The attachment was bad

Original comment by fabien.n...@gmail.com on 18 Feb 2011 at 1:55

Attachments:

• jxtable_tablefilter_control.png

[GoogleCodeExporter]

Hi, Fabien,

I have come with an idea on how to implement it in a non-obtrusive mode: if 
instant filtering is enabled, it only works if the user does not enter any 
operator. In addition, it will do 2 searches: one for the exact input, and, if 
none found, one for the wildcard expression -it can be done very fast, in 
fact-. That is, if the user has entered '11', but there is no such value on the 
column, it will show those matching '11*'

It still does not include all your flexibility, but without adding secondary UI 
-like you did-, I think it would be more complicated and less intuitive to 
handle.

Could you attach a working example of your code? Meme si l'example est en 
francais!

Cheers,

  Lu

Original comment by coderazzi on 21 Feb 2011 at 3:18

[GoogleCodeExporter]

Version 4.1.0 includes the concept of instant filtering.
Implementation is rather different, and not exactly compatible with the 
proposal included in this issue.

Original comment by coderazzi on 14 Mar 2011 at 3:37

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by coderazzi on 14 Nov 2011 at 11:11

• Changed state: Verified