FilteredList/SortedList

[Martin Sladecek]

On 01/16/2013 10:35 PM, Bruce Alspaugh wrote:
> Sorry if I'm a little late to this discussion since I am still very new
> to JavaFX.  Have you taken a look at the approach to ObservableLists
> that the Glazed Lists project takes?
Yes. :-)
As Richard Bair already wrote, the popularity of Glazed Lists in Swing 
was one of the reasons why we want to have similar approach in FX.

>
> An issue I see with the TransformationList is that it only provides
> sorting and filtering transformations.  In general, you could have many
> other types of arbitrary list transformations.  Those transformations
> could depend on multiple ObservableLists or scalar ObservableValues.
> See Glazed Lists for more examples of powerful list transformations.
8.0 will contain only sorting and filtering implementations of 
TransformationList (or maybe more, serving for TableView et al. 
purposes). But this might change in later releases. Also, anybody will 
have a chance to implement it's own TransformationList (by subclassing 
TransformationList), but these TransformationLists will have to be 
created through some constructor, not directly through a ObservableList 
method.

>
> Why not just implement SortedList and FilterList as concrete subclasses
> of ListBinding that are bound to their source ObservableList and an
> observable Comparator or predicate?  For convenience, you could provide
> sort and filter methods to ListExpression that take the appropriate
> observable Comparator or predicate and return another sorted or filtered
> ListExpression so you can chain the calls and build a transformation
> pipeline?
Good question actually!
The main purpose of TransformationList is to provide models for controls 
like ListView or TableView. These models can be anything that implements 
ObservableList (which ListBinding does). But having to put a binding as 
a model or bind a Property<ObservableList> on some control will probably 
be an overkill. The bindings are tightly related to 
ObservableValues/Properties, which means there's one extra layer of 
observability. It's not just the list we'd observe with ListBinding, but 
also changes to the reference to the list itself. Means one extra 
wrapper for every model.

However, I will explore how the TransformationLists will work with 
ListExpression or how we could integrate them.

>
> This makes it possible to add more methods to ListExpression to provide
> more types of list transformations in the future without breaking
> anything, and end users can build their own custom transformations
> simply by providing a concrete implementation of ListBinding and binding
> to the appropriate dependencies.
The same with TransformationList class and new (defender) methods on 
ObservableList. :-)

>
> I haven't had a chance to study the TableView API closely, but you may
> be thinking you need a special interface on SortedList so that TableView
> can change the Comparator on it when the user wants to change the sort
> order.  Is that really true?  Why can't TableView simply make it's
> Comparator properties observable and not be responsible for sorting the
> list at all?  You could provide a convenient TableComparatorChooser that
> registers itself as a listener that responses to changes in the
> TableView comparators by updating the observable sort Comparator the
> SortedList is bound to appropriately.  This borrows some ideas from the
> Glazed Lists approach to sorting a table.
>
> Bruce


-Martin