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
