On 01/16/2013 08:43 AM, Sebastien Blanc wrote:
On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com
<mailto:kris@redhat.com>> wrote:
On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@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(a)apache.org <mailto:matzew@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(a)apache.org <mailto:matzew@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(a)redhat.com <mailto:supittma@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(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@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(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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