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
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
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
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
> 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
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
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,
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
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
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
[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
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
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:
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
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
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
16 matches
Mail list logo
