On 01/16/2013 08:43 AM, Sebastien Blanc wrote:
On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris@redhat.com> wrote:

On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <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@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@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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev




_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev