[aerogear-dev] Client side Paging Spec

Sebastien Blanc scm.blanc at gmail.com
Fri Jan 18 10:12:00 EST 2013 

+1

On Fri, Jan 18, 2013 at 4:05 PM, Summers Pittman <supittma at redhat.com>wrote:

> On 01/18/2013 09:54 AM, Matthias Wessendorf wrote:
> > On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <scm.blanc at 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
> > https://gist.github.com/4537431):
> >
> > My current "page" is "https://localhost/demo/cars?offset=20&limit=10"
> >
> > This means I get something like for next/prev:
> > <https://localhost/demo/cars?offset=10&limit=10>; rel="previous",
> > <https://localhost/demo/cars?offset=30&limit=10>; 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
> Tthat all sounds good.
> >
> >> 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 at 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/specs/abstract_aerogear-client-paging.markdown
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <
> matzew at apache.org>
> >>> wrote:
> >>>> solved...  updating the spec
> >>>>
> >>>> On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris at redhat.com>
> wrote:
> >>>>> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew at apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf
> >>>>>> <matzew at 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 at 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/specs/abstract_aerogear-client-paging.markdown
> >>>>>>>>>>
> >>>>>>>>>> Please review the document!
> >>>>>>>>>>
> >>>>>>>>>> Cheers!
> >>>>>>>>>> Matthias
> >>>>>>>>>>
> >>>>>>>>> +1, let's see how it works in actual implementation!
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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
> >>>
> >>>
> >>> --
> >>> 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
> >>
> >
> >
>
> _______________________________________________
> 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/4e10e9ce/attachment.html

More information about the aerogear-dev mailing list