Maybe I'm doing too much "Thinking in Java", but the child nodes need list
semantics, not map semantics, e.g. for orderable child nodes and same-name
siblings. So this seems like a good idea to me:
[
{ "sling:resourceName": "b",
A: "[property A's value]",
B: "[property B's value]"
},
{ "sling:resourceName": "c",
C: "[property A's value]",
D: "[property B's value]"
},
]
However, since properties do follow map semantics (unique keys, never
orderable), so using the object notation for those makes sense.
And yes, while you can transform objects into arrays and arrays into objects,
you can't effectively do this if you package something needing array semantics
into a map. If a JSON implementation implements objects in a non-orderable way
(which is permitted under the spec and done in the json.org Java
implementation), you can never recover the original order of child nodes. Ditto
with same name siblings.
Justin
________________________________
From: Jonathan Cook [mailto:[email protected]]
Sent: Wed 9/16/2009 10:18 AM
To: [email protected]
Subject: Re: Extending the json renderer
Might be better to wrap the entire object and avoid the pollution with
the "special" property:
[ {name: "A", value: { ... }, {name: "B", value: { ... } ]
Or better yet, write a function to do this client side which your JSON
object is passed to before you use the client lib on it:
function toArray(result) {
var results = [];
for (var prop in result) {
result[prop]["_resourceName_"] = prop;
results.push(result[prop]);
}
return results;
}
If code on the client side is polluting the Object.prototype so that
additional stuff is present on the object returned by JSON, there are
bigger problems!
Regards,
Jonathan 'J5' Cook
Carsten Ziegeler wrote:
> Hi,
>
> I would like to enhance our current json rendering a little bit. The use
> case is using the json output as-is with some javascript client
> libraries: Currently the json output always renders an object
> representation of the requested resource.
>
> Example:
> a / b with props A and B
> a / c with props C and D
>
> doing a /a.-1.json results in:
> {
> "b" : { A : ... },
> "c" : { C : ... }
> }
>
> Some javascript client libs (like extjs) rather work with arrays when it
> comes to collections, so in the case from above an output like
> [ {A : ...} , {C : ...}]
> would be more appropriate.
>
> Therefore I suggest we add the "list" selector to the json servlet:
> /a.list.-1.json would produce the above output.
> The behaviour is to create an array of the child resources of the
> requested resource - the properties of the requested resource are not
> rendered.
>
> To make things a little bit more complicated, in some cases you might
> want to know the original resource name (like "b" and "c" in the example
> from above. And this is actually the ugly part of the proposal. I
> suggest that we use a special property name returning the resource name,
> like:
> [ {sling:resourceName: "b", A : ...} ,
> {sling:resourceName: "c", C : ...}]
>
> Obviously sling:resourceName is not a good choice, so we should come up
> with a more unique name.
>
> Any ideas or comments? :)
>
> Regards
> Carsten
>
