[aerogear-dev] Client Paging Strawman

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


On 01/16/2013 08:43 AM, Sebastien Blanc wrote:
> On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris at redhat.com 
> <mailto:kris at redhat.com>> wrote:
>
>
>     On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf
>     <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>>
>>
>>         Another alternative : What about removing the "page"
>>         attribute and include a "action" attribute inside a "paging"
>>         block ? If paging block isn't present we implicitly know we
>>         don't want paging :
>>
>>         cars.read({
>>              paging:  {
>>                action:  "prev",  //can be "next"
>>                offset:  2,  //optional
>>                limit:  10  //optional
>>         }, success: function( data ) { // do something }, error:
>>         function() { // handle it } });
>>
>>
>>
>>
>>     But the 'updatePageConfig' would be still around ?
>>
>>     If I "touch" (update) the limit/offset, it is globally stored,
>>     and reused, right ?
>>
>>     I always have to provide a paging block, at least like this, right ?
>>     ==> cars.read({
>>         paging: {
>>           action: "prev", //can be "next"
>>         },...........;
>>
>>
>>     BTW. action sounds Struts :)
>>
>>
>>         *General remark *
>>         Do we want to describe in the specs the following use cases ?
>>
>>         - Calling previous on the first page
>>         - Calling next on the last page
>>         - Setting an offset > total number of pages
>>
>>
>>
>>     yeah - would be (more than) nice if that behavior is specified....
>
>     +1 Anyone want to start putting together a specs doc?
>
>
>  Before starting the specs doc, let's first discuss here what for 
> behaviour we want for these specific use cases :
>
> When prev / next does not exist :
> - throwing an exception ?
+1
> - returning null ?
Return is really the wrong word for this since we are all using callbacks.
> - returning the current page ?
-1
>
> For offset > totalNbPages :
> - throwing an exception ?
-1
> - returning null ?
-1, but I could see an argument for returning an EMPTY set
> - returning last page ?
+1 It is possible data will change
>
>
>
>>
>>
>>
>>         On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf
>>         <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>>
>>             Howdy!
>>
>>             I have forked the gist and added the (current) iOS
>>             proposal to it:
>>             https://gist.github.com/4546737
>>
>>             -M
>>
>>             On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf
>>             <matzew at apache.org <mailto: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.
>>             >
>>             > 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")...
>>             >
>>             > 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 <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
>>
>>
>>
>>             --
>>             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
>>             <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 <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
>
>
>
>
> _______________________________________________
> 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/cfad1361/attachment-0001.html 


More information about the aerogear-dev mailing list