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

[Werner Lehmann]

Thanks, Richard and Martin, for the nice summaries. It really helped to 
get back on track on this thread.

On 15.01.2013 19:18, Richard Bair wrote:
> 	5) Sometimes you want a sort or filter to happen clear on the back-end (in the database for example) rather than on the control

Generally speaking, it would be nice to be able to set the sorting 
arrows on columns manually, without getting automatic sort behaviour. 
And for the filtering it would be nice to have an Excel-like special row 
in/under the header for the user to input filter strings. But that is 
for another debate.

> 	1) GlazedLists was popular in Swing, so adopting a similar API design would be popular in FX. Right? :-)
> 	2) By not having TableModel we don't have some view state in the model.

Isnt it possible to have a model without view state? A mutable items 
list. Immutable view for sorted and filtered state. Methods on the model 
to control sorting and filtering. All of this is about the data, not the 
view state.

The control would observe the model state, depend on the immutable view, 
and gets notified when the sorting/filtering state has changed.

> 	3) All indexes have intuitive meaning -- they map exactly to the indexes in the items list

This could be maintained with a model, too. In other words indexes 
always refer to the mutable items list in the model. The list that is 
provided by the user.

> 	4) By just having any old ObservableList as the data items, people are free to give us anything they want [...]
> 	5) Because we sort the supplied ObservableList directly, [...]

That seems possible with the items list as outlined above, and a way to 
manually set the sort arrows on columns in the control. The model would 
not know that its items are already sorted/filtered because the data is 
already supplied like that (e.g. sorted/filtered in SQL).

> The sticking point seemed to be around how to handle add / remove on a FilteredList and SortedList. Specifically, the following are not always true:
>
> filteredList.add(10, item);
> assert item == filteredList.get(10);
>
> int size = filteredList.size();
> filteredList.add(item);
> assert size + 1 == filteredList.size();
>
> sortedList.add(10, item);
> assert item == sortedList.get(10);

That's why I would design those as immutable views. Immutable 
collections are not really unprecedented, e.g. 
Collections.unmodifiable... or Guavas ImmutableXXX classes.

Werner