On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf
<matzew(a)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(a)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/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