On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
+1 to 1) and 2) under the Pipe creation but also 3) , because if one
has a
custom impl for a pipe , he probably needs it for each read
Actually.... since NEXT does change the offset (from
):
My current "page" is
"https://localhost/demo/cars?offset=20&limit=10"
This means I get something like for next/prev:
<
>; rel="next",
So... for iOS... the [next]; (or previous) would INTERNALLY do this:
[_pipe readWithFilter:^(id<AGFilterConfig> config) {
[config setLimit:_limit];
[config setOffset:_offset]; // got increased before
} success:success failure:failure];
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
-M
Okay for PipeConfig.updateParameterProvider() but he should also be able to
pass anytime through the read() to reconfigure , no ? doesn't hurt to have
many options to reconfigure IMO
Just a last remark on the "locations" name : metadataLocation and
pagingLocation are not enough clear to me to see what's coming in and out,
as suggested on IRC : metadataLocationResponse and metadataLocationRequest ?
On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
> Looking at [1]
>
>
> There is ONE detail left...
>
> The paging "config" contains the following settings:
> 1) locations:
> - metadataLocation
> - pagingLocation
> 2) param provider:
> - my custom impl (like in
https://gist.github.com/4564403#comment-732025)
> OR
> - default (limit + offset)
> 3) web linking:
> - nextIdentifier
> - previousIdentifier
>
>
> Now... where to put these options? On the pipe, or on the actual
> "paging read" (e.g. readWithFilter....).
>
> I can see that 1) and 3) are nice on the umbrella Pipe
> definiton/creation. I can also see that it's OK to "install" a
"param
> provider" on the pipe as well...
>
> If the "params" changes (for whatever reason), there could be a
> "PipeConfig.updateParameterProvider()" hook....
>
> I also think..... the parameter provider can be defined on the actual
> read (get request)....
>
> thoughts?
>
> -M
>
> [1]
>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>
>
>
>
> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
> > solved... updating the spec
> >
> > On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com> wrote:
> >>
> >> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org>
> >> wrote:
> >>
> >>> On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf
> >>> <matzew(a)apache.org> wrote:
> >>>>> My suggestion is to name these two parameters something more
generic
> >>>>> like locator/count where locator=page/offset and
count=limit/perPage. Then
> >>>>> in our configs we would provide these options:
> >>>>>
> >>>>> pagingType {String} - determines the paging method to be used
in
> >>>>> calculating next page, etc. and could be either
"offset" or "page", default
> >>>>> "offset"
> >>>>> locatorParam {String} - locator parameter name, default
"offset"
> >>>>> locatorValue {Number} - page index or offset
> >>>>> locatorIdentifier {String} - the locator identifier name,
default
> >>>>> "AG-Paging-Offset"
> >>>>> countParam {String} - count parameter name, default
"limit"
> >>>>> countValue {Number} - items per page
> >>>>> countIdentifier {String} - the count identifier name, default
> >>>>> "AG-Paging-Limit"
> >>>>>
> >>>>> Thoughts?
> >>>
> >>>
> >>> OK.... I agree that you raised a valid concern, regarding that the
> >>> client needs to indicate whether paging information is sent as
> >>> headers, as query parameters, or as body data.
> >>>
> >>>
> >>> But I still am not so sure if the above args are all really needed, a
> >>> ton of cfg params make it a bit fishy.
> >>> How about, using the following as a default "parameter
provider"
> >>> - offset (which sets the offset of the first element that should be
> >>> included in the returned collection)
> >>> - limit (the number of results that should be listed on a page)
> >>>
> >>> OK.
> >>>
> >>> Now if a user wants/needs to provide a different parameter schema
> >>> (imagine his/her lame server requires/supports "page",
"perPage" and
> >>> "sorting"):
> >>> The developer could just create a custom impl (iOS: block, Java:
> >>> anonymus class impl of an interface, JS: callback function) and pass
> >>> it to the "paging request".
> >>>
> >>> that way the dev. could even add a ton of more params (if the lame
> >>> backend requires that).
> >>>
> >>> since the pipe (or the paging request) knows whether the paging
> >>> information is sent as headers, as query parameters, or as body data,
> >>> it would just "serialize" the give "param provider"
into the actual
> >>> location.
> >>
> >> This is the part I don't understand so sorry if I'm the only one
being
> >> dense here. I believe that is basically what we decided to do yesterday,
> >> but, without that initial config, how do I make the initial request for the
> >> first page? Since the callback that the dev would provide isn't
triggered
> >> until a successful read so that it can "build" the next/prev
methods based
> >> on the response, how do I make that first request?
> >>
> >>>
> >>> Any thoughts?
> >>>
> >>> -M
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>> Any news on this ?
> >>>>
> >>>> -Matthias
> >>>>
> >>>>>
> >>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman
<supittma(a)redhat.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> based on today's IRC and mailing list discussions, I
have polished
> >>>>>>> the
> >>>>>>> client side paging spec:
> >>>>>>>
> >>>>>>>
> >>>>>>>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
> >>>>>>>
> >>>>>>> Please review the document!
> >>>>>>>
> >>>>>>> Cheers!
> >>>>>>> Matthias
> >>>>>>>
> >>>>>> +1, let's see how it works in actual implementation!
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> 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
>
>
>
> --
> 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