oxbow icon indicating copy to clipboard operation
oxbow copied to clipboard

Table UI does not respect previous filters

Open eugener opened this issue 13 years ago • 2 comments

More info at http://code.google.com/p/oxbow/issues/detail?id=44

eugener avatar Jul 08 '12 21:07 eugener

This feature looks like a pain to implement. For example, let's say the UI does respect previous filters by reading the possible values from the table instead of the model. If I initially open the filter popup and see:

[x] All [x] Item1 [x] Item2 [x] Item3

If I select "Item2" and apply it, subsequent views of the filter will show:

[x] All [x] Item2

Since the filter popup would only show values that actually appear in the filtered table, there is no way to reselect "Item1" or "Item3" unless all of the filters are reset. This is especially bad if you want to retain a number of filters that you already have applied to other columns.

In order for this to work, you would need a view of the table that does not contain any filters for the current column you wish to display the filter popup for. Easiest way would be to allow the popup to access all of the previous applied filters, take the subset of filters that are not applied to the popup's column, and manually filter the table with the filter subset (as opposed to using JTable's getValueAt() method). At a minimum, the JTableFilter will have to be reworked since the filters are currently composed in a recursive manner (i.e. the only way to remove a filter is to clear them all). The bigger problem is that the actual filtering mechanism is implementation dependent and doesn't necessarily map well between implementations (e.g. the JTableFilter composes RowFilters whereas a GlazedLists-based table would use FilterLists), so it may be difficult to map it back to a simple API to use within filtering GUI.

Additionally, the distinct item caching mechanism would need to be reworked or removed since the cache would need to be reset every time a filter is applied or unapplied. Personally, I have a feeling that the caching cannot be reworked since their isn't a full-proof way to listen to the table for filtering changes (e.g. listening for JTable filtering changes vs. JXTable filtering changes vs. GlazedLists filtering changes).

I think it is technically feasible, but I think a good chunk of the code needs to be redesigned to accommodate this request.

ThePumpingLemma avatar Mar 03 '14 20:03 ThePumpingLemma

Has this issue been resolved yet? I am looking for a smart solution.

muelli1000 avatar Jul 27 '20 10:07 muelli1000