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

Scott Palmer swpalmer at
Thu Jan 10 09:32:19 PST 2013

On 2013-01-10, at 12:00 PM, Richard Bair <richard.bair at> wrote:

>> This doesn't have to break. All existing APIs are View-based.  The current API for setting the items in the table is assumed to be setting the View, since when sorting it is updated in place.
>> There currently isn't any API for setting a model independent of the view, so one could be added.  As long as the list added via the new method is not modified in place and the existing APIs set and return the items in "view" order.. all is well.
>> We need about four new APIs.
>> void setModel(ObservableList)
>> ObservableList getModel()
>> int getModelIndex(int viewIndex)
>> int getViewIndex(int modelIndex)
>> Sorting happens internally on the "Items" list, not the "Model" list.
>> If you call setModel(), a view list ("Items") is created for you and anything you may have set it to previously is toast.
>> If you call setItems(), indicating you wish to use the old API, the model could be forced to null, or a copy of the view list could be made in it's place.  But you have two APIs that are overlapping slightly. That's just what you have to live with.
>> Any existing APIs continue to work based on view coordinates.
> So, the obvious issues:
> 	- As you mentioned the APIs overlap slightly. Or even if they don't the names are ambiguous so there is some sadness that would just have to be lived with
> 	- Because "items" is mutable, we actually have all the same problems Martin is trying to avoid. For example, if the list has been sorted, and you insert an item at a specific location in the items list, then what happens? Once the TableView supports UI for filtering, and you insert and item into items, then what happens?
> The fact that items is mutable I think ruins any chance of using items as the view list?
> Richard

If anything is added or removed from the Items list then the developer has chosen to deal with the old API and not the Model-based API.  If the model is set via setModel then add/remove on the view list should throw.

It isn't ideal, but the options are limited.


More information about the openjfx-dev mailing list