trying to be more clear, instead of having a separate PagingContext to store state, making
a decorator around the results (lazy)
not that I think this is the best - it's just another approach
On 11/01/2013, at 14:58, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Jan 11, 2013 at 5:55 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
> What about returning a PagedList<T> (and using guava's ForwardingWhatever
to decorate the list with the paging info)?
guava :)
well, that's impl details - but overall the 'pseudo' from summersp, I like
-M
>
> On 11/01/2013, at 14:14, Summers Pittman <supittma(a)redhat.com> wrote:
>
>>
>> On 01/11/2013 07:46 AM, Matthias Wessendorf wrote:
>>> Of course, sending simple request parameters to the server is easy, in
>>> every library
>>>
>>> (using Dan's CURL client example)
>>>
>>> ```
>>> URL=
>>>
"http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>
>>> curl -i --header "Accept: application/json"
"$URL/cars?page=0&perPage=4"
>>> ```
>>>
>>> In terms of an client API, that wants to scroll through the cars (like
>>> in this demo), I was wondering if some "PagingContext" (or
>>> "ResultSet") API is needed...
>>>
>>> // issues a request with ?page=0&perPage=4
>>> PagingContext pc = client.request(someCars...);
>>>
>>> // issues a request with ?page=0&perPage=4
>>> pc.next()
>>>
>>> // issues a request with ?page=1&perPage=4
>>> pc.next()
>>>
>>> // issues a request with ?page=0&perPage=4
>>> pc.back()
>>>
>>>
>>> NOT sure, but IMO a little higher level abstraction would be nice,
>>> instead of having the end users of the "paging API" applying the
>>> values for 'page' and 'perPage' manually.
>>>
>>> Any thoughts? (Not sure if this has been brought up before)
>>>
>>> -M
>>>
>> +1 for a higher level abstraction
>>
>> As far as how it will mesh with Pipe and such I am thinking
>>
>>
https://gist.github.com/4511860
>>
>>
>>
>>>
>>>
>>> On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf
>>> <matzew(a)apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> was there already some discussion (and proposal) for paging APIs on the
client ?
>>>>
>>>> It would be nice if the public client API semantics are somewhat
>>>> identical on the different platforms.
>>>> (I guess it's a MUST :))
>>>>
>>>> Any pointers to gists etc are welcome
>>>>
>>>> Thx
>>>>
>>>> --
>>>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev