Re: Filters as views (ISSUE-45)

HI Ruben
>>> – it yields a set of related but different filtered resources (= the 
>>> pages), whereas another filter just results in one filtered resource
>> What makes a collection members filtered by the index subset known as 
>> "page" different than a subset of collection members filtered by i.e. 
>> given name assuming that those items are persons? Page 1 and Page 2 are 
>> in same relation as A Firstnames and B Firstnames.
>And where do the "firstname not filled in" come, before A or after Z? ;-)
>In all seriousness, the A/B example indeed resembles paging.

This touches the situation I mentioned that 'index' is always assigned. 
Filtering on a 'nullable' property will always behave a little bit 
different. But again, assuming that resource identifiers comes, this issue 
is no more.

>However, this does not hold for filters in general.
Well, if assuming that paging is not filter you can put it that way.

>>> – pages have a logical order (as you indicated), and having a "next", 
>>> "previous", "first", "last" link on them makes sense, which is not the 
>>> case for other filters
>> Filtering by a given name gives also a logical order - letters can be 
>> also ordered as numbers. You could state similar links to next and 
>> previous!
>Agree that some filters have a logical next and previous,
>but again, not in general.
But it doesn't make paging anyway special. It fits to those filters that 
hase those relations applicable - thats all.

>>> – membership of a page is altered if new items are added or existing 
>>> items are removed; this is not the case for membership of a filter, 
>>> which is only altered if the item itself is altered (in other words: 
>>> either the index property you describe, or the filter expression that 
>>> selects it, is not a constant)
>> Disagree again. If you assume that order doesn't change your statement is 
>> true. But if the underlying store decide to give you the collection 
>> members in different order paging changes!
>Not sure if we're talking about the same thing here,
>because the fact that paging changes is exactly my problem.
>
>Given an example collection: A A A A A B
>and assume the page size is 5.
>Then we have page 1 (A A A A A) and page 2 (B).
>
>Now remove one of the 1 elements.
>Then we have page 1 (A A A A B), but no second page.
>
>So the membership of B to the page 2 changed,
>even though B itself did not change.
>Whereas for another filter you'd define
>(like: "uneven letters of the alphabet"),
>the membership of B is unaffected.

OK, this differs due to the nature of that 'index' property which is applied 
'here and now', not stored as other ordinary properties.
Anyway, I'm still not convinced that this fact should determine whole 
different approaches and mechanism.

Finally, the only thing I care is to be able to combine both paging and 
filtering easily with a limited number of construct/classes/relations (you 
name it).

Regards

Karol

Received on Tuesday, 12 January 2016 20:00:32 UTC