[aerogear-dev] Client Paging Strawman

Kris Borchers kris at redhat.com
Wed Jan 16 08:08:15 EST 2013


On Jan 16, 2013, at 5:46 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> Hello,
> 
> a few quick/simple q's:
> 
> JavaScript
> 
> One question on the two gists...
> 
> Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist uses pipe.read(page:"next") for the JS.
> 
> 
Actually, my comparison gist that Summers forked uses pipe.read({page:"next"}); I very much prefer that and only had next() prev() methods in my other gists to be in line with the methods the other libraries were providing. If it were up to me, they wouldn't exist in JS.
> I think I do like the 'plain' read overload in JS... - but having a more explicit next() (and others) is not that bad; but (currently) my vote would be pipe.read(page:"prev"......
> 
> 
+1 for just overloading read()
> Oh... What happens when I have a regular pipe, object (where the paged setting is NOT specified on its ctor), and I invoke pipe.read(page:"next") ? I hope it does not issue a JS/type error :-) but I'd expect to have a straight read of ALL the "objects" (or "entities")...
> 
> 
Yes, IMO, all records should be returned in that case and it would just be treated as a "plain" read()
> Android
> 
> You have the following:
> 
> cars.readWithFilter(filter, new Callback<Car>() {
>   @Override
>   void onSuccess(List<Car> data) {
>     firstPage = data;
>   }
> 
>   @Override
>   void onError(Exception ex) {
>     //handle error
>   }
> });
> 
> 
> firstPage.next(.......);
> I am wondering what is the fristPage here (since the data on the onSuccess has been assigned to it)
> 
> Change Offset and Limit
> 
> I like both (JS and Android) :) The Android solution is similar to what I had in mind for iOS...
> 
> I will update the comparison gist soon !
> 
> -Matthias
> 
> 
> 
> 
> On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma at redhat.com> wrote:
> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>> As we wrap the day one of API design discussions, what about summarize the API proposals with usage?
>> 
>> JS/iOS/Android:
>> 
>> 1) usage example, covering some mentioned usecases like changing the paging "midflight" - something really straight to the point (no fluff, just stuff)
> I forked Kris's gist and added android stuff using my proposal (sans blocking methods)
> https://gist.github.com/4542125
> 
> I went for pedantic in a couple of examples...
> 
> 
>> 2) API definition
>> 
>> I think this will give the orthogonal view we need to come to a decision.
>> 
>> kris: What about you providing a snippet of the API you hate too? just for comparison sake :P
>> 
>> -- qmx
>> _______________________________________________
>> 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 _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/c76dad98/attachment.html 


More information about the aerogear-dev mailing list