[aerogear-dev] Client side Paging Spec

[Sebastien Blanc]

+1 with Matthias's suggestion.

On Fri, Jan 18, 2013 at 9: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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130118/54625819/attachment-0001.html