TableView filtering and sorting (was Re: FilteredList/SortedList)

[John Hendrikx]

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?
>
> Richard
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.

--John