You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2009/09/16 15:58:25 UTC
Extending the json renderer
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 and D
doing a /a.-1.json results in:
{
"b" : { A : ... },
"c" : { C : ... }
}
Some javascript client libs (like extjs) rather work with arrays when it
comes to collections, so in the case from above an output like
[ {A : ...} , {C : ...}]
would be more appropriate.
Therefore I suggest we add the "list" selector to the json servlet:
/a.list.-1.json would produce the above output.
The behaviour is to create an array of the child resources of the
requested resource - the properties of the requested resource are not
rendered.
To make things a little bit more complicated, in some cases you might
want to know the original resource name (like "b" and "c" in the example
from above. And this is actually the ugly part of the proposal. I
suggest that we use a special property name returning the resource name,
like:
[ {sling:resourceName: "b", A : ...} ,
{sling:resourceName: "c", C : ...}]
Obviously sling:resourceName is not a good choice, so we should come up
with a more unique name.
Any ideas or comments? :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Extending the json renderer
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Sep 16, 2009 at 16:18, Jonathan Cook <jo...@gmail.com> 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 contain all the data already (assuming the properties of
the node match that data).
> 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:
Good idea, since there might be other client-side libraries that
expect their special format, I'd try and see if you can plug in a
converter on the client side before changing sling. I think a
different built-in rendering makes only sense if it is somewhat
generic - eg. at least 2 use cases ;-) BTW, you could still add the
custom list json renderer in a custom bundle - it doesn't have to be
in the Sling code base, right?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Extending the json renderer
Posted by Carsten Ziegeler <cz...@apache.org>.
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 transformation client side can also be done, but needs to be hooked
into the correct place. And I would repeat myself as well :)
So my idea was to have this out of the box as this seems to be a common
use case - maybe it's not :)
In the meantime my urgent use case disappeared :)
So as it seems that this use case is not that very common and can be
solved in different ways, I think we should leave the json renderer as
is. :)
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: Extending the json renderer
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
same name siblings are allowed, but support of them is optional. See http://www.day.com/specs/jcr/1.0/4.3_Same%E2%80%93Name_Siblings.html and http://www.day.com/specs/jcr/1.0/4.3.2_Support_for_Same_Name_Siblings_is_Optional.html
Justin
________________________________
From: Jonathan Cook [mailto:jonathan.j5.cook@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, there's definitely a case for that. Same name
siblings are not allowed under JCR, are they? So that's not a use case
here.
I am seeing a slippery slope in terms of meaning here and in terms of
terseness of the formats, though. If the frameworks don't like wrapping
the individual nodes, can we wrap the entire object and implement a
list-by-reference to provide ordering?
e.g.
{
list: ["A","B","C","D"],
map: {"D": {...}, "C": {...}, ...}
}
This doesn't handle nested cases, so that probably will not be good enough.
Some kind of nomenclature for providing derived/meta properties should
be created to allow for the objects to have reflecting properties like
this one. Another step down the slippery slope is a meta parent
reference. You can keep going from there now that pandora's object box
is broken!
Is it only necessary to provide these meta properties when this list
selector is used or should they be provided always? We can keep
sliding, I don't know where to stop!
Carsten, in terms of putting it into other builds, etc.... can your
application instead proxy this call and transform the JSON output
according to your exact needs?
Regards,
Jonathan 'J5' Cook
Edelson, Justin wrote:
> Maybe I'm doing too much "Thinking in Java", but the child nodes need list semantics, not map semantics, e.g. for orderable child nodes and same-name siblings. So this seems like a good idea to me:
>
> [
> { "sling:resourceName": "b",
> A: "[property A's value]",
> B: "[property B's value]"
> },
> { "sling:resourceName": "c",
> C: "[property A's value]",
> D: "[property B's value]"
> },
> ]
>
> However, since properties do follow map semantics (unique keys, never orderable), so using the object notation for those makes sense.
>
> And yes, while you can transform objects into arrays and arrays into objects, you can't effectively do this if you package something needing array semantics into a map. 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. Ditto with same name siblings.
>
> Justin
>
>
> ________________________________
>
> From: Jonathan Cook [mailto:jonathan.j5.cook@gmail.com]
> Sent: Wed 9/16/2009 10:18 AM
> To: dev@sling.apache.org
> Subject: Re: Extending the json renderer
>
>
>
> 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 toArray(result) {
> var results = [];
> for (var prop in result) {
> result[prop]["_resourceName_"] = prop;
> results.push(result[prop]);
> }
> return results;
> }
>
> If code on the client side is polluting the Object.prototype so that
> additional stuff is present on the object returned by JSON, there are
> bigger problems!
>
> Regards,
> Jonathan 'J5' Cook
>
> Carsten Ziegeler wrote:
>
>> 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 and D
>>
>> doing a /a.-1.json results in:
>> {
>> "b" : { A : ... },
>> "c" : { C : ... }
>> }
>>
>> Some javascript client libs (like extjs) rather work with arrays when it
>> comes to collections, so in the case from above an output like
>> [ {A : ...} , {C : ...}]
>> would be more appropriate.
>>
>> Therefore I suggest we add the "list" selector to the json servlet:
>> /a.list.-1.json would produce the above output.
>> The behaviour is to create an array of the child resources of the
>> requested resource - the properties of the requested resource are not
>> rendered.
>>
>> To make things a little bit more complicated, in some cases you might
>> want to know the original resource name (like "b" and "c" in the example
>> from above. And this is actually the ugly part of the proposal. I
>> suggest that we use a special property name returning the resource name,
>> like:
>> [ {sling:resourceName: "b", A : ...} ,
>> {sling:resourceName: "c", C : ...}]
>>
>> Obviously sling:resourceName is not a good choice, so we should come up
>> with a more unique name.
>>
>> Any ideas or comments? :)
>>
>> Regards
>> Carsten
>>
>>
>
>
>
>
>
Re: Extending the json renderer
Posted by Jonathan Cook <jo...@gmail.com>.
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, there's definitely a case for that. Same name
siblings are not allowed under JCR, are they? So that's not a use case
here.
I am seeing a slippery slope in terms of meaning here and in terms of
terseness of the formats, though. If the frameworks don't like wrapping
the individual nodes, can we wrap the entire object and implement a
list-by-reference to provide ordering?
e.g.
{
list: ["A","B","C","D"],
map: {"D": {...}, "C": {...}, ...}
}
This doesn't handle nested cases, so that probably will not be good enough.
Some kind of nomenclature for providing derived/meta properties should
be created to allow for the objects to have reflecting properties like
this one. Another step down the slippery slope is a meta parent
reference. You can keep going from there now that pandora's object box
is broken!
Is it only necessary to provide these meta properties when this list
selector is used or should they be provided always? We can keep
sliding, I don't know where to stop!
Carsten, in terms of putting it into other builds, etc.... can your
application instead proxy this call and transform the JSON output
according to your exact needs?
Regards,
Jonathan 'J5' Cook
Edelson, Justin wrote:
> Maybe I'm doing too much "Thinking in Java", but the child nodes need list semantics, not map semantics, e.g. for orderable child nodes and same-name siblings. So this seems like a good idea to me:
>
> [
> { "sling:resourceName": "b",
> A: "[property A's value]",
> B: "[property B's value]"
> },
> { "sling:resourceName": "c",
> C: "[property A's value]",
> D: "[property B's value]"
> },
> ]
>
> However, since properties do follow map semantics (unique keys, never orderable), so using the object notation for those makes sense.
>
> And yes, while you can transform objects into arrays and arrays into objects, you can't effectively do this if you package something needing array semantics into a map. 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. Ditto with same name siblings.
>
> Justin
>
>
> ________________________________
>
> From: Jonathan Cook [mailto:jonathan.j5.cook@gmail.com]
> Sent: Wed 9/16/2009 10:18 AM
> To: dev@sling.apache.org
> Subject: Re: Extending the json renderer
>
>
>
> 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 toArray(result) {
> var results = [];
> for (var prop in result) {
> result[prop]["_resourceName_"] = prop;
> results.push(result[prop]);
> }
> return results;
> }
>
> If code on the client side is polluting the Object.prototype so that
> additional stuff is present on the object returned by JSON, there are
> bigger problems!
>
> Regards,
> Jonathan 'J5' Cook
>
> Carsten Ziegeler wrote:
>
>> 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 and D
>>
>> doing a /a.-1.json results in:
>> {
>> "b" : { A : ... },
>> "c" : { C : ... }
>> }
>>
>> Some javascript client libs (like extjs) rather work with arrays when it
>> comes to collections, so in the case from above an output like
>> [ {A : ...} , {C : ...}]
>> would be more appropriate.
>>
>> Therefore I suggest we add the "list" selector to the json servlet:
>> /a.list.-1.json would produce the above output.
>> The behaviour is to create an array of the child resources of the
>> requested resource - the properties of the requested resource are not
>> rendered.
>>
>> To make things a little bit more complicated, in some cases you might
>> want to know the original resource name (like "b" and "c" in the example
>> from above. And this is actually the ugly part of the proposal. I
>> suggest that we use a special property name returning the resource name,
>> like:
>> [ {sling:resourceName: "b", A : ...} ,
>> {sling:resourceName: "c", C : ...}]
>>
>> Obviously sling:resourceName is not a good choice, so we should come up
>> with a more unique name.
>>
>> Any ideas or comments? :)
>>
>> Regards
>> Carsten
>>
>>
>
>
>
>
>
Re: Extending the json renderer
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Edelson, Justin schrieb:
> 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.
Yes, that's what I tried to say ;-)
>
> 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?
No, we are not ;-)
Sling JSON Render keeps the order amongst child nodes and does not
define any order amongst properties (simply because JCR does not have
such ordering either).
Regarding same-name-sibblings: Well, -- honestly and IMHO -- this is a
flawed concept (and yes, I know why it is in the spec and I also know
that its use is discouraged...). .. And same-name-sibblings is not
supported by JavaScript objects, regardless of any ordering questions...
> 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:fmeschbe@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
>
>
>
RE: Extending the json renderer
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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:fmeschbe@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
Re: Extending the json renderer
Posted by Carsten Ziegeler <cz...@apache.org>.
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 care about order :) It's just about
array vs objects and the resulting problems (like the resource name etc.)
> Thus I don't think anything should be changed in the default json
> output of Sling. For nodes, one can rely on the order in the JSON.
I've looked a little bit more into the problem and it seems that a
general approach is (unfortunately) not worth it - in some situations
it's as easy as my initial proposal but that might only cover 20%.
In other situations you need more "transformation" like flatening the
hierarchy etc.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Extending the json renderer
Posted by Alexander Klimetschek <ak...@day.com>.
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 all those json parsers).
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.
Thus I don't think anything should be changed in the default json
output of Sling. For nodes, one can rely on the order in the JSON.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Extending the json renderer
Posted by Peter Chiochetti <pc...@myzel.net>.
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 guaranteed?
--
peter
Re: Extending the json renderer
Posted by Jonathan Cook <jo...@gmail.com>.
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 just as much as the JS guys?
>>
>
> Wrong. The JSON render renders the child nodes in exactly the order as
> returned from the repository. The properties of nodes (or resources) are
> of course not returned in any defined order simply because the JCR spec
> does not define an order amongst the properties ...
>
So the JSON render is "duck-ordering" the properties of the objects it
creates (they don't have to be JSONObject class to be unordered JSON
objects, they just have to be anonymous objects in javascript notation).
In your other emails you're saying that this property order shouldn't be
relied on. I'm honestly confused about the intention with regards to
ordering in the JSON render.
Carsten's original email says:
"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 and D
doing a /a.-1.json results in:
{
"b" : { A : ... },
"c" : { C : ... }
}"
The output generated does not seem to have any explicit order when it comes to child nodes. When viewed according to the spec and not the colloquial usage, the ordering has been disregarded when the data is transformed from a JCR node and property structure into a javascript object.
I personally don't care whether everything relies on the "duck-ordering" (get all your ducks in a row!). The ordering itself is not even what Carsten is asking about. He's trying to eliminate the duck-ordering and implement explicit ordering and he's run into the problem that ordered objects in JSON cannot have names and is suggesting that an object be allowed to bring that data inside of itself.
He wants to know how to allow for that given that there are possible conflicts with other properties which have been declared on the object. I'm suggesting a specific namespace for derived/meta properties of this kind. I'm also suggesting other ways to wrap the JSON objects to bring the ordering data in without using an explicitly ordered object construct, trying to find out what the community thinks is the best approach.
Regards,
J5
Re: Extending the json renderer
Posted by Felix Meschberger <fm...@gmail.com>.
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 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 just as much as the JS guys?
Wrong. The JSON render renders the child nodes in exactly the order as
returned from the repository. The properties of nodes (or resources) are
of course not returned in any defined order simply because the JCR spec
does not define an order amongst the properties ...
The JSON render does not create an intermediate JSONObject but directly
writes the data out thus keeping the order.
Regards
Felix
>
> I'm trying to argue against introducing any meta properties, but if the
> order is intentionally discarded, and that information is valuable
> (which I think we can agree on) then there definitely should be a way to
> obtain that information. A meta property is certainly the simplest way
> to do that.
>
> Regards,
> Jonathan 'J5' Cook
>
> Felix Meschberger wrote:
>> 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
>>
>>
>
>
Re: Extending the json renderer
Posted by Jonathan Cook <jo...@gmail.com>.
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
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 just as much as the JS guys?
I'm trying to argue against introducing any meta properties, but if the
order is intentionally discarded, and that information is valuable
(which I think we can agree on) then there definitely should be a way to
obtain that information. A meta property is certainly the simplest way
to do that.
Regards,
Jonathan 'J5' Cook
Felix Meschberger wrote:
> 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
>
>
Re: Extending the json renderer
Posted by Felix Meschberger <fm...@gmail.com>.
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
RE: Extending the json renderer
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
Maybe I'm doing too much "Thinking in Java", but the child nodes need list semantics, not map semantics, e.g. for orderable child nodes and same-name siblings. So this seems like a good idea to me:
[
{ "sling:resourceName": "b",
A: "[property A's value]",
B: "[property B's value]"
},
{ "sling:resourceName": "c",
C: "[property A's value]",
D: "[property B's value]"
},
]
However, since properties do follow map semantics (unique keys, never orderable), so using the object notation for those makes sense.
And yes, while you can transform objects into arrays and arrays into objects, you can't effectively do this if you package something needing array semantics into a map. 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. Ditto with same name siblings.
Justin
________________________________
From: Jonathan Cook [mailto:jonathan.j5.cook@gmail.com]
Sent: Wed 9/16/2009 10:18 AM
To: dev@sling.apache.org
Subject: Re: Extending the json renderer
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 toArray(result) {
var results = [];
for (var prop in result) {
result[prop]["_resourceName_"] = prop;
results.push(result[prop]);
}
return results;
}
If code on the client side is polluting the Object.prototype so that
additional stuff is present on the object returned by JSON, there are
bigger problems!
Regards,
Jonathan 'J5' Cook
Carsten Ziegeler wrote:
> 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 and D
>
> doing a /a.-1.json results in:
> {
> "b" : { A : ... },
> "c" : { C : ... }
> }
>
> Some javascript client libs (like extjs) rather work with arrays when it
> comes to collections, so in the case from above an output like
> [ {A : ...} , {C : ...}]
> would be more appropriate.
>
> Therefore I suggest we add the "list" selector to the json servlet:
> /a.list.-1.json would produce the above output.
> The behaviour is to create an array of the child resources of the
> requested resource - the properties of the requested resource are not
> rendered.
>
> To make things a little bit more complicated, in some cases you might
> want to know the original resource name (like "b" and "c" in the example
> from above. And this is actually the ugly part of the proposal. I
> suggest that we use a special property name returning the resource name,
> like:
> [ {sling:resourceName: "b", A : ...} ,
> {sling:resourceName: "c", C : ...}]
>
> Obviously sling:resourceName is not a good choice, so we should come up
> with a more unique name.
>
> Any ideas or comments? :)
>
> Regards
> Carsten
>
Re: Extending the json renderer
Posted by Jonathan Cook <jo...@gmail.com>.
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 toArray(result) {
var results = [];
for (var prop in result) {
result[prop]["_resourceName_"] = prop;
results.push(result[prop]);
}
return results;
}
If code on the client side is polluting the Object.prototype so that
additional stuff is present on the object returned by JSON, there are
bigger problems!
Regards,
Jonathan 'J5' Cook
Carsten Ziegeler wrote:
> 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 and D
>
> doing a /a.-1.json results in:
> {
> "b" : { A : ... },
> "c" : { C : ... }
> }
>
> Some javascript client libs (like extjs) rather work with arrays when it
> comes to collections, so in the case from above an output like
> [ {A : ...} , {C : ...}]
> would be more appropriate.
>
> Therefore I suggest we add the "list" selector to the json servlet:
> /a.list.-1.json would produce the above output.
> The behaviour is to create an array of the child resources of the
> requested resource - the properties of the requested resource are not
> rendered.
>
> To make things a little bit more complicated, in some cases you might
> want to know the original resource name (like "b" and "c" in the example
> from above. And this is actually the ugly part of the proposal. I
> suggest that we use a special property name returning the resource name,
> like:
> [ {sling:resourceName: "b", A : ...} ,
> {sling:resourceName: "c", C : ...}]
>
> Obviously sling:resourceName is not a good choice, so we should come up
> with a more unique name.
>
> Any ideas or comments? :)
>
> Regards
> Carsten
>