FilteredList/SortedList

[Richard Bair]

On Jan 8, 2013, at 10:36 AM, Martin Sladecek <martin.sladecek at oracle.com> wrote:

> On 01/08/2013 06:49 PM, Richard Bair wrote:
>> On Jan 8, 2013, at 9:36 AM, Martin Sladecek <martin.sladecek at oracle.com> wrote:
>> 
>>> 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?) ?
>> Why would it be treated differently? What happens if you take a transformation list and remove an element from it? Does it also remove the element from the underlying list? What happens if you rearrange the items in a transformation list? Does it also rearrange the items in the original list? My assumption was that if you were to do either of these things, it simply updates the mapping. So FXCollections.sort doesn't do anything special -- the TransformationList on the other hand does. When it is told to move items around, it will end up updating its mapping.
> 
> TransformationList is not modifiable. We had a big discussion about this (together with Micheal Heinrichs) about 2 years ago a decided we have to make all TransformationList subclasses unmodifiable as otherwise it would break the List contract. We'd have to have special implementation of sort for the WrappedList.

Oh dear. That is a problem!

>>> 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
>> Right, that's the idea.
>> 
>>> also it might not be clear that you have to use WrappedList for this purpose at first glance.
>> But, you won't get any bugs by accidentally using the wrong index. You will always map correctly from properties on the TableView back to your list. If you find you don't want your original list sorted, then you can discover the solution (wrap it). On the other hand, by having the mapping occur within the TableView, you are guaranteed to have provided an API which will produce bugs. Its just literally guaranteed to happen.
> 
> That doesn't prove WrappedList approach is less error-prone. ;-)
> The people that had it wrong with model-view mapping might make the same bugs with this approach as well, as it's basically also kind of a model-view mapping, it's just called differently.

I don't think so -- in one case it is something you "just have to know" about TableView (that it has two classes of index in different transform space), whereas in other case it is explicit (you had to provide the transformation list so you know there is something going on there). That is the core difference I think.

Richard