Re: [aerogear-dev] Client side Paging Spec

solved... updating the spec On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; 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&gt; 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