FilteredList/SortedList

[Richard Bair]

I don't think it is that complicated. The TableView would continue to sort the items just as it does today. The difference is that the developer can get the original unsorted list and perform view/model mapping by asking the list itself.

That is:

WrappedList items = new WrappedList(original);
tableView.setItems(items);


At any point, my "original" list is going to be untouched. The WrappedList has no comparator or other means for sorting / filtering, it just contains the mapping (say for sake of argument it extends from TransformationList so we can talk in terms of that API, but it wasn't created by sorted / filtered methods). The TableView continues to sort the WrappedList as it does today. In fact, at this point, the TableView would know no more about the WrappedList than it does about a normal observable list.

> tableView.setItems(list);
> TransformationList items = tableView.getViewList();
> // Do something with items
> 
> You don't have to care about Comparator (it's internally managed by the TableView). As we have no special interface for SortedList, there's no way how to change the Comparator through the TransformationList interface. Only table can do that, in case it used sorted(ObservableValue<Comparator>) method.
> If somebody wants some different order, sorted() can be used explicitly:
> 
> tableView.setItems(list.sorted(basicOrderComparator));
> TransformationList items = tableView.getItemsList();
> 
> Column order (if defined & used) always takes precedence over the basicOrderComapartor (as we basically have two sorted lists), and the user-defined order is used when column ordering is turned off.
> 
> No need to special case anything in TableView, no differences in behaviour for different items types (plain ObservableList vs. SortedList), no changes to the provided list.

This is a much nicer suggestion than having the model-to-view conversion methods on Tableview itself (at least it is wrapped up in the TransformationList). However the downside is that the developer still has to know that none of the other indexes provided in the TableView API are in the same transform space as the original list of items -- all indexes are in view indexes (which is different than it is today, meaning all existing code is broken), and that the view list must be used for all index based operations, not the original list.

Richard