FilteredList/SortedList

Jonathan Giles jonathan.giles at oracle.com
Tue Jan 8 00:06:03 PST 2013


I'm probably just being really dense, but I can't see the problem; 
TableView doesn't do anything special when it comes to sorting by 
columns. All I do behind the scenes is create a Comparator and use that 
to sort the list whenever a user/developer modifies the relevant sorting 
properties on TableView and / or TableColumn. When a sort needs to be 
executed, I create a Comparator that first sorts using the Comparator 
from the first TableColumn in the TableView.sortOrder list, and where 
there are two cells that are equal I sort using the Comparator from the 
second column (if one is specified), and so on (using third, fourth, and 
additional columns, as specified in the TableView.sortOrder list).

At present the TableView simply runs this sort on the items list, 
modifying it in place (yuck). However, with the forthcoming availability 
of a sorted list API, can't I continue to do this, but without the need 
to modify the source list (that is, by creating an internal sorted list 
when a sort occurs), and with the benefit that I could trivially return 
to the original unsorted state by getting the source list out of the 
sorted list?

Perhaps you're saying that I need to special case this so that I don't 
change the Comparator set on the sortedList? That is an important point 
to consider: what takes precedence - the Comparator specified by the 
developer against the sorted list, or the one specified by the user when 
they click on columns? But I'm also thinking that I'm simply not 
understanding an important consideration of your sorting / filtering 
APIs, so it would be great to clarify what that is, if that is the case!

-- Jonathan

On 8/01/2013 8:45 p.m., Martin Sladecek wrote:
> Unfortunately, not all cases can be solved naturally by wrapping the 
> list in sorted/filtered wrapper.
> One exception to that is sorting by columns. It's something TableView 
> does internally and it requires some model/view mapping.
>
> While I understand the benefits of having view-model data, I really 
> don't know how to solve this case without the mapping provided by the 
> TableView. If the user would use some filtered/sorted wrapper, his API 
> has to deal with index conversions anyway, using the 
> TransformationList API (the top wrapper being the view, while the 
> original list is in fact the model). E.g. you need this if you want to 
> add something after some item in the table.
> So can't we just say "Hey, use the TransformationList provided by 
> TableView.getViewList() for your model-view conversions instead of the 
> list you passed into setItems()".
> All the indexes in the list will be relative to the getViewList() 
> instead of the items and that's it. The TableView doesn't have to 
> treat different items differently or rely on some weird conditions 
> like having a SortedList in the chain (which it does now if you look 
> at TableView.sort()). So, every kind of ObservableList would just work 
> (mutable, immutable, transformation, ...) without some special 
> treatment from the TableView.
>
> -Martin
>
>



More information about the openjfx-dev mailing list