same name siblings are allowed, but support of them is optional. See http://www.day.com/specs/jcr/1.0/4.3_Same%E2%80%93Name_Siblings.html and http://www.day.com/specs/jcr/1.0/4.3.2_Support_for_Same_Name_Siblings_is_Optional.html Justin
________________________________ From: Jonathan Cook [mailto:[email protected]] Sent: Wed 9/16/2009 11:43 AM To: [email protected] Subject: Re: Extending the json renderer 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:[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 >> >> > > > > >
