Re: Filters as views (ISSUE-45)

Hi Markus

I'm happy to deliberate on this with you! Especially when I disagree :)

>> Consider that each element of the collection has an index - a value that 
>> is not directly assigned, but it's bound to that item whatever you'll do.
>>In this approach paging is nothing else than a filter on that property 
>>(index).
>Even then, paging is still different, because:
>– 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.

>– 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!
Another example would be filtering by dates (I think I put that example in 
the collection paging discussion). What makes it so different? Dates by 
nature have their "next" and "previous" links regardles the unit (minutes, 
months, etc.)!

>– pages typically have a fixed result size, which is not the case for other 
>filters
It's just typical - its easier for us. But nothing stands against pushing 
variable sized pages. This actually is sometims a case when you see 
"More..." button. System may decide to provide different number of items 
(i.e. depending on how much screen size they would occupy). That's why I 
prefer limit/offset than page/pageSize. The former can do all that can be 
done with the latter, but not the opposite.

>– 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!

>– for pages, the sum of the related resources (= other pages) always yields 
>the entire collection; in contrast, not every filter always has its 
>negation implemented (e.g., an application might allow you to search by 
>keyword, but not necessarily by things that not contain the keyword)
But this is just a consequence that each collection member has this 'index' 
assigned. Filtering by a property that is for some collection items missing 
makes your statement correct.
This is the only thing that makes it a little bit different - property on 
which the filtering is applied always exists. But to think of it it's not so 
different as filtering on resource identifier, which also exists (event if 
it's blank) leads to same observations.

I really don't see a difference here.

Best

Karol

Received on Tuesday, 12 January 2016 19:10:10 UTC