FilteredList/SortedList

[Jonathan Giles]

>> These lists have always been driven by the requirements of TableView,
>> but I'm having a hard time understanding how the newly proposed API will
>> fit in (and what will be required of me and / or end users of the
>> TableView control). It would be great if you could show some examples of
>> how a developer would instantiate a TableView that is:
>
> Generally, this shouldn't mean any changes to TableView at all. The 
> consumers of FilteredList/SortableList should not see them as such, 
> but simply as implementations of ObservableList.
>
> The task of TableView is to observe an ObservableList and update 
> itself according to changes of the list. These changes may be the 
> result of adding, removing, sorting, filtering and on. How the list 
> changes themselves is not something TableView (or other controls that 
> listens to ObservableLists) should care about.
In theory this is true, but there are always edge cases. What should 
happen when a user clicks on a TableColumn header and wants to modify 
the sort order - do we modify the sorted lists comparator or not? If we 
do, how do we return to the original state of a sorted list (we'd have 
to store the comparator and reapply it - but only if the list is a 
sorted list). If we do need to special case for a sorted list, how do we 
know that we've got a sorted list?
>
>> 1) always in a sorted state
>
> First, it may not always be desireble to have a TableView that is 
> always in a sorted state, so a way to configure this 
> (autoSortProperty) would be needed.
This was the reason I was hoping to tease out code examples for this and 
the option below...
>
>> 2) able to filtered based on a user typing
>
> This would be the task of the API user to hook up a FilteredList with 
> a suitable filter (with mutable predicate based on values of other 
> controls) to the TableView.
Yes, I know this is how it would be done in general, but I'm keen to 
understand how it would be done using the current API that Martin is 
proposing. It is hard to understand what may be missed (as you note 
above) without getting a feel for the API.
>
>> 3) is always sorted and able to be filtered based on user input
>
> For sorting, I think TableView should implement it with an internal 
> SortedList. That is, the user hooks up an ObservableList to the 
> TableView, but internally TableView wraps with in a SortedList and 
> uses the latter as the source for the display. This way you can, as 
> you say, also revert to the unsorted if so desired. 
This is another reason why TableView needs to know what kind of list it 
is dealing with - wrapping a SortedList (provided by the user) in 
another SortedList is redundant, and again the edge cases rear their head...

> An open question here is whether this sortedList should be exposed, 
> which may be desirable if the user *actually* wanted to use the sorted 
> list for something (which is the current behaviour with sort in place...)
>
> So in this sense, SortedList might be driven by the needs of 
> TableView, while FilteredList would be completely unrelated. 
> FilteredList might have som uses with ComboBox, though. (E.g. "find" 
> or narrow the possibilities as the user types.)

-- Jonathan