Making the distinction between the list and map semantics shows the
problem more clearly. If the problem is preserving the order of child
nodes in the JSON output, there's definitely a case for that. Same name
siblings are not allowed under JCR, are they? So that's not a use case
here.
I am seeing a slippery slope in terms of meaning here and in terms of
terseness of the formats, though. If the frameworks don't like wrapping
the individual nodes, can we wrap the entire object and implement a
list-by-reference to provide ordering?
e.g.
{
list: ["A","B","C","D"],
map: {"D": {...}, "C": {...}, ...}
}
This doesn't handle nested cases, so that probably will not be good enough.
Some kind of nomenclature for providing derived/meta properties should
be created to allow for the objects to have reflecting properties like
this one. Another step down the slippery slope is a meta parent
reference. You can keep going from there now that pandora's object box
is broken!
Is it only necessary to provide these meta properties when this list
selector is used or should they be provided always? We can keep
sliding, I don't know where to stop!
Carsten, in terms of putting it into other builds, etc.... can your
application instead proxy this call and transform the JSON output
according to your exact needs?
Regards,
Jonathan 'J5' Cook
Edelson, Justin wrote:
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:jonathan.j5.c...@gmail.com]
Sent: Wed 9/16/2009 10:18 AM
To: dev@sling.apache.org
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
