[aerogear-dev] Client side Paging Spec

[Matthias Wessendorf]

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