[aerogear-dev] Client Paging Strawman

Sebastien Blanc scm.blanc at gmail.com
Wed Jan 16 08:43:22 EST 2013 

On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris at redhat.com> wrote:

>
> On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <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 ?
- returning null ?
- returning the current page ?

For offset > totalNbPages :
- throwing an exception ?
- returning null ?
- returning last page ?




>
>
>>
>>
>> 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
>>
>>
>
>
> --
> 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/aa17e9bf/attachment-0001.html

More information about the aerogear-dev mailing list