FilteredList/SortedList

[Martin Sladecek]

On 01/07/2013 07:25 PM, Richard Bair wrote:
>> I find it really strange that TableView modifies the list I put into it
>> when I sort it.
>>
>> Say I have an Domain model like this:
>>
>> Person {
>>   private ObservableList<Address> addresses;
>> }
>>
>> Address {
>>   private String street;
>>   ....
>> }
>>
>> and I put the a persons address list into a table view, I would not
>> expect you to modify it when the table gets sorted. I think you need to
>> keep a sorted/filtered copy internally but leave the original list in
>> place. BTW what would happen if I pushed an immutable-list into it, it
>> would fail on sorting right?
> On the other hand, maintaining an internal data model inside the table view means that we must expose API allowing you to map from selected indexes to "natural" indexes, and vice versa. And not just selection but any API associated with indexes now needs to be defined in terms of view / model and conversions, AND every single use of these APIs in every single application has to take into account that the model / view indexes might not be the same (and I can guarantee that a sizable number of applications will get this wrong).
>
> That's the basic problem with handling the mapping within the control. There will be many applications which don't care whether their original list is sorted, and for the others you can wrap the list in an intermediate sorted / filtered wrapper (which then has all the API on it for mapping from source -> destination indexes and back again). This seems much cleaner to me. From a theoretical perspective you have to decide whether model data is what is set on a control, or view-model data is what is set on the control. We decided on view-model data (which sometimes maps directly to model data, and sometimes doesn't).
>
> Richard

Unfortunately, not all cases can be solved naturally by wrapping the 
list in sorted/filtered wrapper.
One exception to that is sorting by columns. It's something TableView 
does internally and it requires some model/view mapping.

While I understand the benefits of having view-model data, I really 
don't know how to solve this case without the mapping provided by the 
TableView. If the user would use some filtered/sorted wrapper, his API 
has to deal with index conversions anyway, using the TransformationList 
API (the top wrapper being the view, while the original list is in fact 
the model). E.g. you need this if you want to add something after some 
item in the table.
So can't we just say "Hey, use the TransformationList provided by 
TableView.getViewList() for your model-view conversions instead of the 
list you passed into setItems()".
All the indexes in the list will be relative to the getViewList() 
instead of the items and that's it. The TableView doesn't have to treat 
different items differently or rely on some weird conditions like having 
a SortedList in the chain (which it does now if you look at 
TableView.sort()). So, every kind of ObservableList would just work 
(mutable, immutable, transformation, ...) without some special treatment 
from the TableView.

-Martin