Felix Meschberger wrote: > The spec is actually very clear: The order amongst properties in objects > is explicitly undefined. That is, code must never expect properties to > have a specific order. Right, but implementations may choose (as it appears most JavaScript browser engines do) to implement an object in such a way as to retain order. In any case, we're absolutely in agreement that dependence on this behavior is dead wrong. But are we also in agreement that the Sling JSON renderer is flawed in so far as it doesn't support ordered child nodes and same name siblings? I don't see a good way to change this without breaking backwards compatibility.
Justin ________________________________ From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Wed 9/16/2009 2:02 PM To: dev@sling.apache.org Subject: Re: Extending the json renderer Hi, Edelson, Justin schrieb: > ... 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. The spec is actually very clear: The order amongst properties in objects is explicitly undefined. That is, code must never expect properties to have a specific order. The problem is that browser JavaScript interpreters are implemented providing a property order, namely the order of property definition (similar to the ordering of the LinkedHashMap in Java) and client-side java scripters unfortunately tend to depend on this "feature". Regards Felix
