[aerogear-dev] Final version (hopefully) (was: Re: Client side Paging Spec)

[Kris Borchers]

A couple of comments:

In https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#request--and-pipe--level

"The Pipe is responsible to maintain the paging requests (e.g.next or previous), by using the given identifiers."

I thought some of our recent changes were so that the pipe was not maintaining those but there were in fact part of the response and the dev would have to use them via the response object, not the pipe (though the actual read() would happen in the pipe with a config passed via next or previous). Not sure of the best way to word this but seems confusing as is.

In https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#default-parameter-providers

I am still not a fan of calling the default params offset* and limit*. My concern is that if my app doesn't use offset, it would be confusing to me to set offsetIdentifier to "page" and offsetValue to 1 because I am using paging and my pages start at 1. When someone looks at that code, is it an offset of 1 or page 1 assuming I don't know the inner workings of the paging implementation.

Also, what happens if I want to just call it something else because those names confuse me so I create my own page param via the parameter provider. Since I didn't do anything with offsetValue and offsetIdentifier, now my request might look like cars?page=2&offset=0 because the default was added in on top of my values. Again, maybe I'm missing something but I think a rename of those options to something with less "meaning" would help prevent future confusion.

In https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#methods

"NOTE: When scrolling outside of the allowed range (e.g. invoking next on the last page), the server should return an empty list."

We can't control what the server returns so 1) we shouldn't make this statement and 2) the client libs should be able to handle any success response whether there is data or not and also any error response.

On Jan 18, 2013, at 10:23 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> Published the lastest version:
> 
> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#the-paging-configuration
> 
> PS: the file name sucks, but that's not important ... :)
> 
> On Fri, Jan 18, 2013 at 4:12 PM, Douglas Campos <qmx at qmx.me> wrote:
>> On Fri, Jan 18, 2013 at 03:54:19PM +0100, Matthias Wessendorf wrote:
>>> So... I think this is already impl detail, but when there ARE no
>>> meta-information for NEXT/PREV available,
>>> the user has to maintain that himself.... so passing the (updated)
>>> parameter provider on the read is nice....
>>> 
>>> Christos and I tend to do that for iOS. I guess Summers will be on the
>>> same page (haha) with his Android code
>> 
>> +1 here - totally makes sense :)
>> 
>> -- qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130118/e66dd5a2/attachment.html