On Jan 22, 2013, at 3:50 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 22, 2013 at 10:37 AM, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
> Interesting point Kris !
> Not sure how we can provide a simple and robust solution that works for all
> the cases. Maybe as you said, we follow a convention, that the info is at
> the root and otherwise the developer could use a custom function (as we do
> for sending paging info) to consume lpaging metadata.
yeah - something like a "provider" (function would work).
I think I can get on board with that.
We can't catch every server API :)
> Seb
>
>
> On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>>
>> On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com>
>> wrote:
>>> [Reposting from GMail because Red Hat account is blocked again]
>>> Thinking more, we could probably just keep the defaults undefined, that
>>> way they only define if they need them, otherwise the root of the response
>>> is assumed which would probably work better since for example, Twitter
>>> encapsulates the data but the paging is at the root of the response.
>>>
>>
>> Ah... ok, thanks for the example - I ran into that yesterday evening
>> as well, when testing parsing of the TW info...
>>
>> Here is, I think, what you define "result container"
>> {
>> "next_page": "some value..",
>> "prev_page": "moar value...",
>> ...
>> more 'flat' data....
>> ...
>> }
>>
>> There is a flat JSON response, that has the desired values at the root
>> level of the response.
>>
>> Yesterday, I was wondering if there are server that do a more
>> structured (think Java/XML) response
>> {
>> "metadata": {
>> "next_page": "some value..",
>> "prev_page": "moar value...",
>> // other metadata....
>> },
>> /// more structured results...
>> }
>>
>> So yeah... that does not work, right now... But what happens if they
>> have even a bit deeper nesting (you never know why...).... I am now
>> just thinking XPath :) but I see your point, since I had that same
>> thought yesterday, after parsing twitters bits.
>>
>>
>> -M
>>
>>
>>
>>> On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>>
>>>> I've hit one small snag. If the paging metadata is returned in the
>>>> body, it would probably be useful for the developer to be able to specify
a
>>>> "paging container" and/or a "results container" since
each of those pieces
>>>> of information would probably be encapsulated from the other in any sane
>>>> server implementation. I would suggest something like metadataContainer
and
>>>> dataContainer with defaults of "paging" and "data" as
defaults but I am
>>>> totally flexible on those.
>>>>
>>>> Thoughts?
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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