RE: Express "go to specific page" for a collection

Hi Pipo,

On Tuesday, July 08, 2014 11:42 AM, Philipp Zins wrote:
> > Does your use case really require it?
> 
> I would say, yes. If you compare some GUI pagination patterns (see
> https://gist.github.com/mislav/622561) you can see that roughly 50%
> allow the user to jump to an arbitrary page.

When it comes to GUIs it is indeed an often used pattern. The question however is, if this really needs to be supported by the API directly as well. It depends entirely on the application I would say. How often does a user jump from page 1 to page 213 and then back to page 49? If it doesn't happen often (and it isn't needed to support certain use cases), it's better to avoid supporting it directly IMO. The client can prefetch the next x pages and then render direct links just to those pages (1 2 3 4 .... last page).

It all depends on the use case. I would thus like to have a concrete scenario that really requires it, i.e., that can't be solved otherwise. Do you have one?


> What do you think about Jindřich comment with the anonymous anonymous
> property?

Jindřich said:

  Instead of using hydra:freetextQuery for hydra:property mapping in
  the hydra:IriTemplateMapping, I think you can use an anonymous
  property with rdfs:range defined to be xsd:positiveInteger:
  
  "property" : {
    "rdfs:range" : "xsd:positiveInteger"
  }
  
  Although I'm not sure if using anonymous properties in such case is
  an accepted practice in Hydra.

I wouldn't use an anonymous property in this case as it is crucial for the client to understand what the property is about. Just telling the client that the value should be a positive integer isn't enough IMO. The client needs to know that this represents the page number. It also needs to know if the first page is 0 or 1 or if the page number is actually an offset (11 instead of 2 for page 2 if each page has 10 items).


> Some background: I'm mainly a frontend developer switching to the
> backend here and there. As we try to move more development processes
> to the client (for better iteration speeds, dynamic and fluid GUIs,
> etc.) we need a good interface between server and client. We really

That's great. AFAIK, we didn't have (m)any frontend developers in the group till now. So your input will be very helpful to improve Hydra.


> like the idea of Hypermedia APIs (instead of RPC-ish "REST" APIs) and
> I try to evaluate different solutions. We currently favor JSON Hyper-
> Schema directly embedded in our resources,

Could you tell us why you currently favor JSON Hyper-Schema and briefly explain how you use it on the frontend? For example, do you use it to automatically generate forms?


> but I would like to explore
> if we can move to Hydra/JSON-LD completely in the next turn as it
> seems to be a more widely used standard and because JSON-LD is
> supported by all major search engines. But I don't want to loose the
> benefits of JSON Hyper-Schema.

What are those benefits? Apart from the "go to specific page" feature, what else is currently missing in Hydra in your opinion?


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 8 July 2014 11:17:59 UTC