[aerogear-dev] Client side Paging Spec
Matthias Wessendorf
matzew at apache.org
Fri Jan 18 09:54:19 EST 2013
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
>
> 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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
More information about the aerogear-dev
mailing list