martin.sladecek at oracle.com
Thu Jan 17 01:01:54 PST 2013
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?
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
> 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
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
> 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.
More information about the openjfx-dev