TableView filtering and sorting (was Re: FilteredList/SortedList)
lehmann at media-interactive.de
Wed Jan 16 04:05:19 PST 2013
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
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();
> 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.
More information about the openjfx-dev