But if we go for this solution, we must also add in the usage page a section showing a custom impl to pass the parameter. <br><br><div class="gmail_quote">On Fri, Jan 18, 2013 at 9:32 AM, Sebastien Blanc <span dir="ltr"><<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 with Matthias's suggestion.<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Fri, Jan 18, 2013 at 9:25 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>> wrote:<br>
>> 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:<br>
>><br>
>> pagingType {String} - determines the paging method to be used in calculating next page, etc. and could be either "offset" or "page", default "offset"<br>
>> locatorParam {String} - locator parameter name, default "offset"<br>
>> locatorValue {Number} - page index or offset<br>
>> locatorIdentifier {String} - the locator identifier name, default "AG-Paging-Offset"<br>
>> countParam {String} - count parameter name, default "limit"<br>
>> countValue {Number} - items per page<br>
>> countIdentifier {String} - the count identifier name, default "AG-Paging-Limit"<br>
>><br>
>> Thoughts?<br>
<br>
<br>
</div>OK.... I agree that you raised a valid concern, regarding that the<br>
client needs to indicate whether paging information is sent as<br>
headers, as query parameters, or as body data.<br>
<br>
<br>
But I still am not so sure if the above args are all really needed, a<br>
ton of cfg params make it a bit fishy.<br>
How about, using the following as a default "parameter provider"<br>
- offset (which sets the offset of the first element that should be<br>
included in the returned collection)<br>
- limit (the number of results that should be listed on a page)<br>
<br>
OK.<br>
<br>
Now if a user wants/needs to provide a different parameter schema<br>
(imagine his/her lame server requires/supports "page", "perPage" and<br>
"sorting"):<br>
The developer could just create a custom impl (iOS: block, Java:<br>
anonymus class impl of an interface, JS: callback function) and pass<br>
it to the "paging request".<br>
<br>
that way the dev. could even add a ton of more params (if the lame<br>
backend requires that).<br>
<br>
since the pipe (or the paging request) knows whether the paging<br>
information is sent as headers, as query parameters, or as body data,<br>
it would just "serialize" the give "param provider" into the actual<br>
location.<br>
<br>
Any thoughts?<br>
<span><font color="#888888"><br>
-M<br>
</font></span><div><div><br>
<br>
<br>
<br>
<br>
<br>
><br>
><br>
> Any news on this ?<br>
><br>
> -Matthias<br>
><br>
>><br>
>> On Jan 17, 2013, at 12:23 PM, Summers Pittman <<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>> wrote:<br>
>><br>
>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote:<br>
>>>> Hi,<br>
>>>><br>
>>>> based on today's IRC and mailing list discussions, I have polished the<br>
>>>> client side paging spec:<br>
>>>><br>
>>>> <a href="https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown" target="_blank">https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown</a><br>
>>>><br>
>>>> Please review the document!<br>
>>>><br>
>>>> Cheers!<br>
>>>> Matthias<br>
>>>><br>
>>> +1, let's see how it works in actual implementation!<br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
<br>
<br>
--<br>
Matthias Wessendorf<br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>