Re: Call for consensus for the pagination design (ISSUE-42)

Hi Karol,

Via Boxer senden
Am 23.10.2015 13:36 schrieb karol.szczepanski@gmail.com:
>
> Hi Dietrich 
>
> >I would suggest to use hydra:IriTemplate. The url query params can be 
> described by its mappings. 
> >You put hydra:search on the collection, its value is an IriTemplate. At 
> least the situations below can be covered nicely by it. 
> I'm aware of it - I'm doing it in my projects already (I think so - the spec 
> site doesn't give too much of the examples on how to properly implement it) 
>
> > Certainly worth a thread of its own. But let us keep this out of this call 
> for consensus for the view construct - unless it prevents a consensus for 
> you. 
> Well, if the consensus is just about deciding whether the view approach is 
> good or not it doesn't prevent a consensus for me.  But if we're trying to 
> improve the spec for hypermedia controls I'd like also to reflect all 
> necessary changes (if any) in the API documentation part. I hate job done in 
> half. 
>

Maybe this helps to sort things out: The PartialCollectionView solves a different concern than querying. It partitions a collection which for some reason decided solely by the server is presented in partial views. It has navigation controls to move between the partitions.

Those controls use URLs which are opaque to the client. The fact that the sample  view used a query url with a page parameter accidentally brings up the question if the client could use those parameters to control the content of the collection. I would say, that is not what the next/previous URLs are for.

The construct for such custom queries is the IriTemplate. Such a query could return a partitioned collection, but otherwise, executing queries should really be kept separate from the concern of  partitioning and controlling 
navigation inside partial views.

I also see the IriTemplate as the place where the server can offer some control over the paging to clients, i.e. by defining an IriTemplate with limit and offset parameters - which caused heated discussions in the past, so much that we got stuck. Therefore I tend to go forward step by step this time, but collect open points along the way.

This thread is about the consensus about the relationship between collection and partial views (see subject ;-) ). Query language and custom partitioning schemes are important, but can come later.

We could then update the spec with the new collection construct and implementations can come out of experimental status, as far as collections are concerned. Hence i am interested to close this issue.

I am not the moderator, but these are my 2 cts :-)

Cheers,
Dietrich