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
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!
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.
More information about the openjfx-dev