[aerogear-dev] Client Paging Strawman

[Kris Borchers]

On Jan 16, 2013, at 6:38 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Some new questions : 
> 
> JavaScript
> 
> cars.updatePageConfig({
>     offset: 2,
>     limit: 10
> });
> can we also shortcut this way ?
> 
> cars.read({
>     page: "prev",
>     pageConfig: {
>       offset: 2,
>       limit: 10
>     },
>     success: function( data ) {
>         // do something
>     },
>     error: function() {
>         // handle it
>     }
> });
> 
> 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
>     }
> });
> 
I think I like this idea but I have a concern. Would this permanently change the paging context or is this just a temporary change for a single read? I think it could be useful to have have this for doing things like jumping to a particular page, but I think it would be confusing if it didn't change that "global" page context. IMO, I think it would be better to only modify offset and limit in the updatePageConfig method and only allow a shortcut to turn paging off via read({page: false});  Any other opinions on that?

> 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
> 
> 
> On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <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> 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>
> > 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
> 
> 
> 
> --
> 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
> 
> _______________________________________________
> 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/6d5be8ef/attachment-0001.html