Hi,
continue on with what Summers said about the "scrollingMetaDataLocation" in
iOS[1] I have a question.
I believe these are the parameters that can override the behaviour for paging (taken by
the JS gist here [2]):
a) "scrollingMetaDataLocation(iOS) or paged(js) // "headers" or
"content" to describe where to find the paging metadata,
b) "offset": {String} // override the name of the "offset" param
either in the header or in the content, default is "AG-Paging-Offset" for header
and "paging.offset" for content
c) "limit": {String} // override the name of the "limit" param either
in the header or in the content, default is "AG-Paging-Limit" for header and
"paging.limit" for content
d)"total":{String} // override the name of the "total" param either in
the header or in the content, default is "AG-Paging-Total" for header and
"paging.total" for content
e)"next":{String} // override the name for the "next" link either in
the header or in the content. Default is undefined
f) "prev":{String} // override the name for the "prev" link either in
the header or in the content. Default is undefined
So, as Summers said, I believe all these params must be set upfront, instead of passing
the possible overridable params when we create a readWithFilter. That is, it is fine when
we do the first "readWithFilter", but it will become cumbersome when afterwards
need to change the limit offset param and we need to pass along again these params.
So my question, where should we add these config parameters? In a separate object (e.g.
PageConfig) that will hold these params and then be set on the PipesConfig object during
the creation of the pipe?
I believe that is what JS does now. On android[3] I see that these parameters were added
in the existing PipesConfig object
Any thoughts?
Thanks,
Christos
[
1]https://gist.github.com/cbff741b3b21a50c3b67
[2]
https://gist.github.com/4531575
[3]
On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
> I tweaked the iOS API a bit more:
>
https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like
encoding or authentication) instead of a request level thing? I don't imagine it
changing during the lifetime of a Pipe?
Otherwise looks really good!
> I also updated the "comparison" gist:
>
https://gist.github.com/4546737
>
> Feedback welcome....
>
> On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> the timeout parameter would be a general property of read() and not related
>> to Paging ?
>>
>>
>> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>>>> Good point Summers. Might be an obvious question, but there we go. Are
>>>> we planning to include timeout as parameter? For example: I want to
retrieve
>>>> a list of a bazilion users, and I want to specify the timeout acceptable
to
>>>> wait.
>>>>
>>>> I didn't get the chance to look at each API, just double checking
here.
>>>>
>>> +1
>>>
>>> I was thinking about this yesterday. I want to but was hoping we could
>>> get the "shape" of the API nailed down first before we started
hammering
>>> on specifics.
>>> _______________________________________________
>>> 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
>>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev