Hi,
Am Donnerstag, den 07.04.2011, 06:47 +0100 schrieb Tobias Bocanegra:
> 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]
To be clear: The ECMAScript standard explicitly states, that there is
*no* order to be assumed amongst the properties. As a consequence JSON
(and the JSON library we use) do *not* guarantee an order.
> most of the ecma runtimes have stable child
> objects.
which is "legal" according to the spec but leads to false assumptions,
unfortunately....
> 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.
No, they don't suffer from the problem. They are perfectly right. We
suffer by assuming an order.
> 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
Again (sorry): We should not rely because the expectations may and will
fail... (as we now see in reality, and I have heard some browser vendors
even don't have ordered properties any longer ...)
> 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 ?
I like the idea of a special property and I like the "special" character
used. Maybe we could just use a regular "illegal" property name like
":child-node-order" or ":sling:child-node-order" instead of a single
character.
Using the colon prefix would also make sure, that such a property if
sent back to the Sling POST Servlet would just be ignored.
I am not so much concerned with performance (I would assume the ordering
information overhead is minimal). I am more concerned with backwards
compatibility. Unfortunately existing clients will not expect additional
properties and thus side effects may happen if we just add them. So in
the interest of stability, I would suggest we add a required selector to
get back the child node order property.
Regarding information on supported child node ordering: I would assume
that we could add such information to the ResourceMetaData of JCR Node
Resources.
To conclude:
+1 to extend JcrNodeResource to provide the orderable child node
attribute of the node type to the ResourceMetaData
+1 to optionally provide a synthetic child node order property
+1 to requiring a new selector to request the child node order
property
+1 to omit the child node order property if the parent node does
not support child node ordering (as indicated by the
ResourceMetaData property).
Regards
Felix
>
> 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
