Re: [aerogear-dev] Client side Paging Spec

On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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(a)apache.org&gt; > 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/spe... >> >> >> >> >> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >>> 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 >> >> >> -- >> 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 >