[aerogear-dev] Client Paging Strawman

Summers Pittman supittma at redhat.com
Wed Jan 16 10:41:10 EST 2013


On 01/16/2013 06:46 AM, Matthias Wessendorf wrote:
>
> Hello,
>
> a few quick/simple q's:
>
>
>       <https://gist.github.com/2d75e480500c69993227#javascript>JavaScript
>
> One question on the two gists...
>
> Kris' gist <https://gist.github.com/4539188> uses |pipe.next()| of 
> scrolling forward, Summer's comparison gist 
> <https://gist.github.com/4542125> uses |pipe.read(page:"next")| for 
> the 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".....|.
>
> 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")...
>
>
>       <https://gist.github.com/2d75e480500c69993227#android>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)
>
firstPage is a field with a type of PagedList
>
>
>       <https://gist.github.com/2d75e480500c69993227#change-offset-and-limit>Change
>       Offset and Limit
>
> I like both (JS and Android) :) The Android solution is similar to 
> what I had in mind for iOS 
> <https://gist.github.com/cbff741b3b21a50c3b67>...
>
> I will update the comparison gist soon !
>
> -Matthias
>
>
>
>
>
> On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma at redhat.com 
> <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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/258f109b/attachment.html 


More information about the aerogear-dev mailing list