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

Matthias Wessendorf matzew at apache.org
Wed Jan 16 09:57:19 EST 2013


Follow-up question,

in the previous gist, we have:

var pagedPipe = AeroGear.Pipeline({
    name: "cars",
    settings: {
        paged: "headers"
    }}).pipes.cars;

so.. here you would basically "bloat" the settings with values like:
"next", "first", "paged", "limit", "offset" etc - right ?

I am currently thinking if we should do (at least on the iOS side of
things) the same... that would mean... there is no longer an AGFilterConfig
thing.....


-Matthias


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

> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/bb01d095/attachment.html 


More information about the aerogear-dev mailing list