[aerogear-dev] JS pipe ctor for paging (was: Re: Client Paging Strawman)

[Matthias Wessendorf]

on the IRC I asked this:

MW: https://gist.github.com/4539188 - when creating a pipe, with the
'paged' settings - I could apply the offset/limit there too, or "just" via
updatePageConfig() invocation ?

KB: the point of that gist was to sort out the differences in read()
between the libs so i left it out.

MW: thanks


-M



On Wed, Jan 16, 2013 at 3:21 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
> On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris at redhat.com> wrote:
>
>>
>> On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>> If the data doesn't exist HTTP 204 is a good fit. Just don't understand
>> why we need to interrupt the app workflow, because the data doesn't exist.
>>
>>
>> I would prefer that an exception is thrown client side before a request
>> is ever sent to the server. That way we save the http request which is
>> important on mobile.
>>
>
> Ah! yeah - good point -> since the "paging API" knows there is no "next"
> (for instance)
>
>
>>
>> That being said, then the issue becomes what if that page does exist but
>> we don't allow the request because the data was updated since our last
>> read? Then we wouldn't know without another read happening.
>>
>
> yeah - here could the 2.x targeted feature of 'sync' come in...
>
>
>>
>> Hmmm, interested in other opinions since relying on a 204 or any status
>> from the server couples the client to the server impl but if we don't allow
>> the request, that could also cause issues.
>>
>
> true :)
>
>
>>
>>
>> --
>> "The measure of a man is what he does with power" - Plato
>> -
>> @abstractj
>> -
>> Volenti Nihil Difficile
>>
>>
>>
>> On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>>
>>
>> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris at redhat.com (
>> mailto:kris at redhat.com <kris at redhat.com>)> wrote:
>>
>> I would say returning the current page would be confusing. I would be
>> fine with an exception or returning null as both can be handled pretty
>> easily by a dev. I would say an exception may be more useful since it will
>> tell the dev exactly what was wrong instead of their app choking in a null
>> return but I am open to both.
>>
>>
>> For offset > totalNbPages :
>> - throwing an exception ?
>> - returning null ?
>> - returning last page ?
>>
>>
>>
>>
>> I would say same as above. Returning last page may be confusing but
>> others are acceptable with a preference toward an exception.
>>
>>
>>
>> +1 on an exception
>>
>> -M
>>
>>
>>
>> --
>> 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<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
>>
>>
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/87817d4d/attachment.html