FilteredList/SortedList

[Tom Schindl]

Am 04.01.13 05:08, schrieb Jonathan Giles:
> On 4/01/2013 8:39 a.m., Knut Arne Vedaa wrote:
>> I'd say: don't special case, don't treat the items list as anything
>> else than an ObservableList, don't try to know what you're dealing
>> with, don't guess with the API user wants. If they provide a
>> SortedList and you wrap it with a new SortedList there will be
>> redundancy - but that's the user's responsibility. You provide the
>> API, the user may use it or abuse as they wish.
> When designing API it is my goal to try to give the most useful API I
> can. I think that, in the case of SortedList, if I can special case it
> to, for example, allow for returning back to an unsorted state (which is
> something I get asked for a lot), it is worth having it in there (rather
> than requiring a developer to manually watch for the tableview sortOrder
> list to become empty and then set the tableview items list based on the
> sortedList.getOriginalSource(), or, even worse in the case of
> ObservableList, maintain a copy of their original unsorted items list).
> Returning to an unsorted state when there are no columns being sorted is
> what a user expects, so it seems like a reasonable thing to support by
> default if I can?
>>
>> Let's look at a use case:
>>
>> Say you (as API user) have three TableViews beside each other. They
>> are all backed by the same list, which happens to be a SortedList (for
>> reasons unknown). You want to view them as independently sorted. If
>> now the TableView says "aha! we already have a sorted list, so we can
>> just use that for sorting!", obviously all views will be effected by
>> the sorting, which is not what you want.
> I'm not entirely clear here with what you're saying. Using the same
> SortedList for three TableViews (based on the current impl in 2.x) will
> result in the display of all three tables being synchronized when
> sorting happens in any one of them. I have a feeling we're saying the
> same thing, but I just wanted to be clear.
> 
> Also, I'm not entirely sure this isn't what you'd expect. The flip side
> of your argument is the people who put one list into multiple tableviews
> and are confused when their state is not modified across all three.
> Personally I would probably fall into this camp. One rule we try to have
> in JavaFX is to not do any magic if we can help it - so wrapping a list
> (and presumably returning that wrapped list on getItems() calls) would
> be at least a little confusing (i.e. when getItems() does not
> necessarily equal setItems(items)).

I find it really strange that TableView modifies the list I put into it
when I sort it.

Say I have an Domain model like this:

Person {
  private ObservableList<Address> addresses;
}

Address {
  private String street;
  ....
}

and I put the a persons address list into a table view, I would not
expect you to modify it when the table gets sorted. I think you need to
keep a sorted/filtered copy internally but leave the original list in
place. BTW what would happen if I pushed an immutable-list into it, it
would fail on sorting right?

Tom

-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834