TableView filtering and sorting (was Re: FilteredList/SortedList)
hjohn at xs4all.nl
Sun Jan 20 13:18:50 PST 2013
On 18/01/2013 19:02, Richard Bair wrote:
>> Werner Lehmann writes: "Generally speaking, it would be nice to be able
>> to set the sorting arrows on columns manually, without getting automatic
>> sort behaviour."
>> +1 All we really need to be able to do is to set the arrows manually,
>> and register for a callback when the user clicks in the column headers.
>> As developers, we should be able to decide how we want to handle thatI
>> callback. If we decide to sort the list, the TableView will see that
>> the list has changed and redraw itself accordingly.
>> Perhaps you could move the sorting functionality you have now into a
>> default handler that responds to mouse clicks in the header by changing
>> the arrows and sorting the list. But that default can be replaced by
>> the developer. Then there would no longer be a need to make a
>> distinction inside TableView between view and model indexes.
> I agree I think that having this as pluggable behavior is the right thing to do. Jonathan, is there already a JIRA for it?
I've just read through most of this thread, and I agree with Werner as
well. TableView should not have to deal with filtering and sorting
itself, it should simply provide events and users can sort their model
accordingly (and wrap it accordingly if they donot want to modify their
base model). This also opens up fancy sorting tricks like having
secondary sort columns depending on the order the user clicked, having
tri-state columns (sorted, reverse sorted, not sorted), or allowing
column headers to be used for selecting a whole column.
If you want to provide an all-in-one solution out of the box and ready
to use, a factory to create a properly configured TableView comes to
mind. This factory will simply wire the events to respond to user
clicks by sorting the model. None of that code should be in TableView
itself: the factory should provide the sorting logic.
Another reason I would prefer to keep this seperate from the UI View
classes is performance related. In Swing, there are some use cases
where standard JTables perform very poorly when they need to be kept
sorted. An example is a sorted directory of 100000 files. Select half
of them by some criteria (filesize/date) and then delete them from the
JTable. Performance in Swing was so poor that the files very faster
deleted from the underlying disk then from the View representing them
(apparently, the swing TableView equivalent will do a full resort and
reindex after every modification -- totally unacceptable behaviour that
does not scale well at all).
After changing this to a model based approach where the model was kept
sorted (ie, not using the sort functionality of the JTable), the speed
was much better. It was even better after replacing the ArrayList model
with one that had O(log N) performance for inserts/removes.
More information about the openjfx-dev