FilteredList/SortedList

[Martin Sladecek]

On 01/08/2013 05:59 PM, Richard Bair wrote:
> 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.

I don't understand how this would work. Currently, the TableView calls 
FXCollections.sort on items.
So the WrappedList would be some special kind of ObservableList which 
would be treated differently by FXCollections.sort and it will just 
store the new order of elements and provide mapping for it (through 
TransformationList interface?) ?

This means all items list that we do not want to be manipulated by a 
TableView will have to be wrapped in WrappedList, otherwise they will be 
sorted directly.
So for a modifiable lists we would get:

tableView.setItems(list); // sorted directly
tableView.setItems(wrapped = new WrappedList(list)); // wrapped 
maintains the mapping, list is not modified

... and for unmodifiable lists (which might be also something user wants 
to display in a TableView):

tableView.setItems(list); // not possible to use sorting, will this 
throw some exception? (Jonathan?)
tableView.setItems(wrapped = new WrappedList(list)); // wrapped 
maintains the mapping, list is not modified

also it might not be clear that you have to use WrappedList for this 
purpose at first glance.
>
>> 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
What about deprecating items property, leaving the behavior as-is + 
introducing setModel() and getViewList() for the newer code?

-Martin