FilteredList/SortedList

[Richard Bair]

On Jan 8, 2013, at 9:54 AM, Knut Arne Vedaa <knut.arne.vedaa at broadpark.no> wrote:

> Richard Bair wrote:
>> WrappedList items = new WrappedList(original);
>> tableView.setItems(items);
> 
> Disregarding technicalities / implementation details, conceptually this could be ok, but in terms of API-friendliness I don't think it's an improvement over Martin's suggestion, rather the opposite.
> 
> The needed knowledge for the API user would be "TableView may mutate your list, if you don't want that to happen, simply wrap your list in a WrappedList, but be aware that any index you get from TableView will be relative to the wrapped list and not your original list, but you can use the getOriginalIndex() method on WrappedList to convert between them".
> 
> While on the other hand, if the logic is internally on TableView, it would be "just give your list to TableView, but be aware that (due to possible sorting) viewIndex will be relative to the displayed list, while modelIndex will be relative to your original list (which will remain untouced)".
> 
> Which one has the least cognitive tax? IMO clearly the latter.

That is where I disagree, I think the former is clearly easier. At least we know from SwingLabs / Swing that the latter approach (which we used in both those projects) certainly led to a host of errors in peoples applications due to using the wrong index (and often of course this didn't show up in a person's program until runtime because they didn't test all their functionality on a sorted list!). There was also a huge discussion / disagreement over what state the different indexes (such as selection & focus) where in -- model state or view state. And huge discussions about which one to use and the parties involved never came to any conclusion.

By having the UI control simply act on the list provided, there is no question what any index relates to. And the fact that there is mapping involved is clearly defined by the wrapping mechanism used. And (we didn't talk about this yet) -- sometimes you want to filter & then sort, sometimes you want to sort & then filter, or perhaps provide a series of transformations. By having a chain of such things easily available to the developer, we make it easy for the developer to explicitly influence in what order things occur.

I think it is much clearer to separate the mapping etc. out of the control and into the model.

Richard