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

[Richard Bair]

OK, so lets explore what life would look like if we tried to do the sorting internally to the TableView (and everything here also applies to the TreeTableView. ListView and TreeView have no intrinsic UI for sorting, although one could imagine that we would want to add DnD reordering as a feature to both ListView and TreeView, and this would therefore exhibit the same sort of pathologies that we are exploring in TableView. So although we're talking about TableView, all of these issues are actually applicable to TreeView, TableView, ListView, and TreeTableView).

I'm not interested in deprecating (although for completeness, I'm glad it came up). So lets see if there is another way to deal with the problem.

The following APIs presently refer to either "row" or "index" on TableView:
	- edit(int row, TableColumn col)
	- scrollTo(int index)
	- getEditingCell (returns a TablePosition)
	- getFocusModel (returns a TableView.TableViewFocusModel)
	- row factory (creates a TableRow)
	- getSelectionModel (returns a TableView.TableViewSelectionModel)

Each TableRow has an "index"
TablePosition has a "row"
TableCell has an "index" (to be honest I don't even know what this index is -- row index I would guess?)
TableView.TableViewFocusModel has:
	- focus(int index)
	- focus(int row, TableColumn col)
	- getModelItem(int index)
	- isFocused(int row, TableColumn col)
	- focus(TablePosition)
TableView.TableViewSelectionModel has:
	- clearAndSelect(int row, TableColumn col)
	- clearSelection(int row, TableColumn col)
	- getTableModel() "returns getTableView().getItems()"
	- getTableView() "returns the table view"
	- isSelected(int row, TableColumn col)
	- select(int row, TableColumn col)

There might be more "index" / "row" based methods or properties, but I got all the ones I could find. It is a pretty large list! It seems self evident to me that changing the meaning of any of these is going to introduce very serious bugs not only in compatibility but going forward -- developers are constantly going to be stymied. But anyway, let us press on :-).

We could say that "anything named 'row' is view based, and anything named 'index' is model based" and then adjust the names of the various API accordingly. This at least would have the benefit of providing guidance in the API names as to whether the integer is model or view based. That at least would make it so that, compatibility breakage aside, future developers would know what is what (after they first get bit, anyway, they will have some means of avoiding future dental encounters).

Now the big debate is what each of the various methods means. We could say they are all view based or all model based, and then provide convenience methods to translate. However this scheme will fail. The "index" on a TableRow and a TableCell must be view-based, because this index is used to determine even/odd striping. Therefore, it must be view-based. However we cannot make everything view-based since all existing code will break, since it rightly assumes that the model remains in sync with the view and therefore all indexes are model based.

So what we would have to do is to provide new properties on TableRow and TableCell for the "row", separate from the "index" which is the model index, and update the "even" "odd" pseudo classes to be based on "row" instead of "index".

So I think if we were to try to change the design of Tree/Table/List/TreeTable such that sorting etc. was done within the control, the only way to do so would be to add "rowIndex" or whatnot to TableRow, TableCell, TreeCell, ListCell, etc. We'd have to accept the fact that anybody who was relying on the view index & model index being the same would break (which is a serious thing to consider doing!). All indexes would be in terms of model indexes and API would be added (maybe just having a single getter to get the "viewItems" as Martin suggested) so that developers could map from model to view and vice versa.

I just wanted to go through the complications here so that when we're considering which way to go we don't assume that this path is the easiest, or that it would be impossible. I *think* it would be possible to do this, what we would break is any time a developer were to have assumed that they were working with view indexes (such as the scrollTo method might not scroll where they thought it would anymore).

Richard