RE: Filters as views (ISSUE-45)

Just answering your comments that I won't answer in other mails later

On 8 Feb 2016 at 23:19, Karol Szczepański wrote:
>> The server decides to paginate here, not the client. I used page=x as URL
>> parameter for the sake of simplicity but I could (and probably should) have
>> also used an arbitrary token which the client wouldn't be able to construct
>> easily.
> 
> Well, I'm not sure why client shouldn't be allowed to construct these kind
> of controls on it's own.
> Indeed, it's up to the server to paginate or not and to tell the client on
> how to do it or not.
> The paging example you provided disallows client to change both page and
> filter specification at the same time.

I'm not saying the client shouldn't be allowed to construct this. Client-initiated paging is important and we will come to it. But that's a separate discussion. We are stuck with these collection discussion for a long time now if we keep rehashing the same things and side-tracking discussions instead of focusing on particular aspects we won't make any progress. So, please accept that we will discuss this - just not now.


>> Unfortunately, no one commented on filterSpecification so far. I would love
>> to hear your thoughts about that.
>
> Let me be the first though. It remind's me a bit of a SPIN constructs, but
> this isn't a surprise - those are binary operators. Only thing that concerns
> me here is the operand's precedence. It might be useful to enforce a
> specific order of the operands, i.e. from optimization point of view. It's
> sometimes worth of putting a specific operand first before others in the
> "AND" chain so the whole filter fails soon enough to prevent it from
> deep-diving further.

The server can obviously optimize it in whatever way it wants. Semantically, however, the order doesn't matter.


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 10 February 2016 21:09:54 UTC