[aerogear-dev] Client side Paging Spec

[Matthias Wessendorf]

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