Re: Filters as views (ISSUE-45)

On 2016-01-12 21:00, Karol Szczepański wrote:
>> 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).
>

I agree with this sentiment. It seems that you guys are discussing quite 
specific cases of filtering and paging. Both terms actually mostly 
associated with collections. Just as most of your examples.

In this sense I do agree with Markus that it is important to design a 
solution flexible enough to address any scenario. This is where the term 
"view" is more appropriate IMHO, given that one can derive a resource 
not only from collections but any resource in general.

Received on Tuesday, 12 January 2016 20:13:56 UTC