Re: Extending the json renderer

2009-09-16 Thread Carsten Ziegeler
Alexander Klimetschek wrote: > > But I think Carsten's problem is not about the order at all - it's > just that a javascript client library (ExtJS) typically expects arrays > for data and not objects. And it's about JCR properties, which aren't > ordered anyway. Yes, right, Alex - I actually don't

Re: Extending the json renderer

2009-09-16 Thread Alexander Klimetschek
Hi all, to clear up the discussion (even if it was already noted somehow): ordering is not meant to be supported in the JSON spec, but the whole stack we are talking about supports it: jcr nodes (depending on node types), sling json export and all common browser javascript implementations (plus al

Re: Extending the json renderer

2009-09-16 Thread Peter Chiochetti
In other news, Dojo.data prefers arrays over objects. e.g. it likes to consume the children of a node as a list of objects rather than properties of the parent object. A sample (cp=childproperty): items: [ { cp1: A, cp2: B }, { cp1: B, cp2: C } ] Maybe thats because otherwise ordering was not

Re: Extending the json renderer

2009-09-16 Thread Jonathan Cook
Devil's advocacy continues below. Felix Meschberger wrote: Your statement seems to show that the ordering information is intentionally and willfully discarded in the JSON render, because the render is not implemented in an orderable way. Is that the intention or is the JSON render duck-ordering

Re: Extending the json renderer

2009-09-16 Thread Felix Meschberger
> I don't see a good way to change this without breaking backwards > compatibility. What needs to be changed breaking backwards compatibility ? Regards Felix > > Justin > > > > > From: Felix Meschberger [mailto:fmesc...@gmail.c

Re: Extending the json renderer

2009-09-16 Thread Felix Meschberger
Hi, Jonathan Cook schrieb: > Felix, > > Pardon me playing devil's advocate a little here, especially since I > suggested a post-processing step that relies on the "feature" you > mention ;) > > Real world implementations always trump the spec! It talks like a duck! > > Your statement seems to

RE: Extending the json renderer

2009-09-16 Thread Edelson, Justin
blings? 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,

Re: Extending the json renderer

2009-09-16 Thread Jonathan Cook
Felix, Pardon me playing devil's advocate a little here, especially since I suggested a post-processing step that relies on the "feature" you mention ;) Real world implementations always trump the spec! It talks like a duck! Your statement seems to show that the ordering information is inte

Re: Extending the json renderer

2009-09-16 Thread Felix Meschberger
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

Re: Extending the json renderer

2009-09-16 Thread Carsten Ziegeler
Wow, I did't expect that much responses. Thanks for all the ideas and suggestions! Now, I can write a special server side component generating the correct json format. But I don't want to do this over and over again. And doing some transformation on the fly is also possible and doing the transform

RE: Extending the json renderer

2009-09-16 Thread Edelson, Justin
[mailto:jonathan.j5.c...@gmail.com] Sent: Wed 9/16/2009 11:43 AM To: dev@sling.apache.org 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

Re: Extending the json renderer

2009-09-16 Thread Jonathan Cook
ermitted 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

RE: Extending the json renderer

2009-09-16 Thread Edelson, Justin
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:

Re: Extending the json renderer

2009-09-16 Thread Alexander Klimetschek
On Wed, Sep 16, 2009 at 16:18, Jonathan Cook wrote: > Might be better to wrap the entire object and avoid the pollution with the > "special" property: > > [ {name: "A", value: { ... }, {name: "B", value: { ... } ] I think this doesn't work for ExtJs, because it expects objects = records that cont

Re: Extending the json renderer

2009-09-16 Thread Jonathan Cook
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 t