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

[Matthias Wessendorf]

On Fri, Jan 18, 2013 at 5:53 PM, Kris Borchers <kris at redhat.com> wrote:
> 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.

I mean, in order to simply say next(); the value for the offset on the
"rel=next;" needs to be applied
to the NEXT request, right ? I am trying to say that the pipe does
that. Why the pipe? Well, the read() is a method
on the pipe.... so, for me (OO world) when the read() uses that
information, the pipe somewhat does it. Makes sense

If yes, can you update the above with "proper" English ?



>
> 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.

actually the "AG-Paging-Offset/Limit" RESPONSE headers have been
removed from the reponse.

Custom params -> "param provider" (which is up the the actual impl)


>
> 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.

if your server has no offset, than provide a "param provider".
If you start sending bogus bits to the server... well, you asked for trouble...

>
> 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

yes

>  and 2) the client libs should be able to handle any success
> response whether there is data or not and also any error response.

thx - backed that into the spec


-Matthias

>
> 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
>
>
>
> _______________________________________________
> 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