Re: Filters as views (ISSUE-45)

February 8 2016 9:46 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: 
>>> I'm just a bit uneasy about multiple PartialCollectionViews, each with
>>> it's own totalItems.
> 
> Yeah, I find that a bit confusing as well but in order to make this unambiguous to a machine we
> need them I guess.
> 

Do we? Please exaplain

>>> I think that there should only be one such view in
>>> a response.
> 
> How would you communicate to a client then that the response was not only filtered, but that the
> server also decided to paginate it?
> 

Does it matter to the client? The client should only care that there are more pages (linked) and how to possibly construct different views.

>>> In my opinion, if GETting /markus/friends?first=Ruben
>>> redirects (or uses Content-Location header) than the view is actually
>>> the first page and not the initial target.
> 
> While that might work for the first page it would make it more difficult to get the total number of
> filtered items. Also, how would that work for page 2, 3 and so on?
> 

I don't understand. If /markus/friends?first=Ruben has a totalNumber = 20 and the server redirects to /markus/friends?first=Ruben&page=1, which contains 5 items, this doesn't change the fact that the total number of items is still twenty.

>>> Also I'm not sure about mixing both ViewTemplate and View on single
>>> `view` property.
> 
> We can certainly split it into two properties but I'm not sure that would buy us much. What
> advantages would you see?

As a client I wouldn't have to inspect each individual element of 'view' to determine whether it's a View or a ViewTemplate. Simple as that, Separation of Concerns, and thus simpler client implementation.

Received on Tuesday, 9 February 2016 11:48:51 UTC