You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
More info at http://code.google.com/p/oxbow/issues/detail?id=44
The text was updated successfully, but these errors were encountered: