[aerogear-dev] Client side Paging Spec

Summers Pittman supittma at redhat.com
Fri Jan 18 10:05:26 EST 2013 

On 01/18/2013 09:54 AM, Matthias Wessendorf 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
Tthat all sounds good.
>
>> 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
>>
>
>

More information about the aerogear-dev mailing list