On Jan 16, 2013, at 11:17 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Kris,
our server uses these param names, as default, for the actual query
string, on the URL
*limit
*offset
*where
looking at your gist (
https://gist.github.com/4531575), I don't see a
config to override the actual value of the above param names (e.g. to
use page, perPage etc).
The ''offset" argument is more to define the actual header information
(the name, where to look on the response), right ?
Yes, exactly. The "offset" arg is where you could rename it as "page"
and the "offsetVal" is where you give it a default value.
-M
On Wed, Jan 16, 2013 at 4:24 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
>
> On Jan 16, 2013, at 8:57 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> 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 ?
>
>
> Actually, no. I'm thinking there would be a config in settings in addition to the
paged setting. I want to keep that out of the config so it's easier to set that to
false without the need to redo the whole config. The page config will actually have a
number of items to keep the impl flexible. So there will be both a setting for what the
"next" header or content metadata var is called and same for the others.
>
>
> 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(a)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(a)apache.org>
wrote:
>>>
>>>
>>>
>>> On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com>
wrote:
>>>>
>>>>
>>>> On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)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(a)redhat.com
(mailto:kris@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(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev