[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