On Jan 18, 2013, at 11:26 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Jan 18, 2013 at 5:53 PM, Kris Borchers
<kris(a)redhat.com> wrote:
> A couple of comments:
>
> In
>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>
> "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 ?
I'll take a look.
>
> In
>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>
> 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.
That's fine for us but the clients still need to work with any random header the
server decides to send as paging info so somewhere this needs to be customizable just like
the params. Not all servers are going to follow the Web Linking standard (RFC 5988) and we
still need to work with them.
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".
So what
you're saying is if a param provider is used, the defaults are completely thrown out?
If that's the case then this is fine.
If you start sending bogus bits to the server... well, you asked for
troubleā¦
Agreed, I just thought it would happen without the dev actually wanting it.
Based on the previous statement though, this is not an issue.
>
> In
>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>
> "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(a)apache.org> wrote:
>
> Published the lastest version:
>
>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>
> PS: the file name sucks, but that's not important ... :)
>
> On Fri, Jan 18, 2013 at 4:12 PM, Douglas Campos <qmx(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev