hi,
the JSON serialization that sling uses to generate json responses
assumes that the consumer creates a object representation that has a
stable child object ordering. although this is not mandated neither by
JSON [0] nor by ECMA [1] most of the ecma runtimes have stable child
objects. but for example the default org.json.JSONObject uses a plain
HashMap for the child objects, that's why sling has an extended
version that uses a LinkedHashMap.
i recently played with the JSONDecoder in Flash which just creates
plain AS Objects, which don't have a stable order, so i had to create
an own decoder that feeds a specialized AS JSONObject. I assume that
other runtimes (.NET, PHP, etc) might suffer from the same problem.
see also [2] and [3] that talk about that.
especially when dealing with WCM content, where the ordering is
important (order of paragraphs, order of child documents, etc), this
might be a problem that such implementations can't rely on their
default json lib, when they want to access a resource tree remotely.
this all leads to the question, if the JSON response of sling should
be extended to alleviate the transport of a stable child resource
ordering. the probably simplest and backward compatible extension
could be to additionally include an array with the child resource
names, for example:
{
"p1": "hello world",
"a": { ... },
"b": { ... },
"*": ["a", "b"]
}
the special array "*" would contain the names of the child resources
in the order provided by the resource resolver. the special name "*"
should minimize the risk for collisions with existing nv pairs. also
note, that the order of the "properties" is not relevant to clients
(as, for example, it is not given for JCR properties, xml attributes,
nv pairs in java properties files, etc).
the resource resolver could even be extended to expose the information
about if child resource ordering is given at all (for example only jcr
nodes with 'orderable child nodes' have this behavior). if the oder
can not be provided by the underlying system, the "*" array should be
omitted.
including this array per default would generate some overhead by
increasing response sizes and client memory consumption and also
decreasing decoding performance. so it might makes sense to either
make it configurable, or to deduce it somehow from the request
(special header, special extension, special selector). also, i would
only include it, if the depth level is high enough to already include
the child resources (e.g. foo.0.json would not include the "*" array).
WDYT ?
regards, toby
[0] http://www.json.org/javadoc/org/json/JSONObject.html (A JSONObject
is an unordered collection of name/value pairs...)
[1] http://interglacial.com/javascript_spec/a-4.html#a-4.3.3
[2]
http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-javascript
[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
