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

[Richard Bair]

> OK, seems like we all dug our trenches and this is not going to move anywhere.

:-)

> As I see it, we have 2 very similar solutions (let's call them W(rapper) and M(odel)-V(iew)) with the following aspects:
> * Both have 2 different "modes", with mutable/immutable model. Mutable model is used by default and will be always used when executing an old code. Immutable model is triggered by using a wrapper (W) or using setModel() method on the control (M-V).

Actually I am still calling into question that the wrappers would be unmodifiable.

> * In both cases, using immutable model require extra work and extra caution in order to have the indexes right.
> * M-V require additional methods for all affected controls, while W needs a new class or a defender method on ObservableList.
> * M-V handles sort internally in the control, while with W, an external object is modified by the control.
> 
> Anything else?
> 
> 
> I also thing we didn't explore details on Richard's solution much. I have some questions about how the implementation would look like:

Yes, now that we've explored the M-V situation, we need to explore the wrapper situation. Once we've done both we should have lots of reasons to hate both approaches :-).

> * The WrapperList will be something tightly associated with our controls or some general-purpose wrapper? In case of the latter, what will be it's functionality then? A special wrapper that can be sorted by FXCollections.sort() while leaving the wrapped list untouched? Or maybe it will be a special class that also allows direct sort calls?
> 
> (Note that it must be something like FXCollections.sort() as there is no sorting method on List and Collections.sort() uses clear() + add()).

This is a good question and I'm not sure yet. Initially the idea was to have general purpose filter / sort wrappers (like with Glazed Lists) and then we wouldn't actually have to do much special in the UI controls at all. However as we had explored previously, mutable filtered lists might be in violation of the general contract of a List, and thus wouldn't be generally useful as a list. In such a case, it might still be worth having such a creature, but have it specially designed for controls and in the controls package.

> * How will the developer know that the WrapperList is the list to be used?

It somewhat depends. If I had it to do over, I might have started off with a control specific implementation of ObservableList as the model for the control. Maybe that is still a way to go, such that although you can specify any ObservableList you want, we default to a TableViewModel (instance of ObservableList) and have a TableViewModel class in the control package. It would be fairly natural and discoverable in that case.

> * What about TableView's encapsulation? What if something else tries to use the same WrapperList that is used by the TableView?

If we had a SortedList, the idea was that I could have a single ObservableList as the backing data model and then wrap it by two different SortedLists and provide these SortedLists to the two different TableViews. In this way each table view sorts the sorted list, not the backing data model.

Thanks
Richard