[aerogear-dev] Client side Paging Spec

Kris Borchers kris.borchers at gmail.com
Fri Jan 18 10:02:42 EST 2013 

I think this all makes sense for JS. The impl might be slightly different, especially since we won't have anything like readWithFilter but the spirit will be the same.

On Jan 18, 2013, at 8:54 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 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
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

More information about the aerogear-dev mailing list