On Fri, Jan 18, 2013 at 9:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
But if we go for this solution, we must also add in the usage page a
section
showing a custom impl to pass the parameter.
On Fri, Jan 18, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
>
> +1 with Matthias's suggestion.
>
>
> On Fri, Jan 18, 2013 at 9: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.
>>
>> 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