Hi,
Am Donnerstag, den 07.04.2011, 20:46 +0100 schrieb Eric Norman:
Yes, but if order is important it seems more correct to send an array. And
adding a psuedo 'order' property isn't backward compatible either.
I see, but ...
As has been said, the current JSON export has the nice side-effect
On 11.04.11 05:50, Felix Meschberger fmesc...@adobe.com wrote:
Am Freitag, den 08.04.2011, 12:04 +0100 schrieb Alexander Klimetschek:
On 08.04.11 08:01, Carsten Ziegeler cziege...@apache.org wrote:
maps rarely have an order regardless of the language.
A linked map is not an unusual data
While I see the reasons behind just adding an order property, I agree
with Eric that if you want to have an ordering use an array - maps
rarely have an order regardless of the language.
This is about adding a new format, so both client and server needs to
implement this - therefore I think we're
well, as alex said, the format is quite cool and very useful when it's
used in an ecma script environment. and i guess the order is not often
used. and if you wish to iterate, then you can just use the
child-names array, eg:
for (var name in obj[:child-names]) {
var child = obj[name];
}
Tobias Bocanegra wrote
well, as alex said, the format is quite cool and very useful when it's
used in an ecma script environment. and i guess the order is not often
used.
Well...if the order is not used, the old format is perfect, right? :)
and if you wish to iterate, then you can just use
On 08.04.11 08:01, Carsten Ziegeler cziege...@apache.org wrote:
maps rarely have an order regardless of the language.
A linked map is not an unusual data structure. As Tobi noted, WCM/CMS is a
prominent use case.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
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] most of the ecma runtimes have stable child
objects. but for
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]
On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote:
the special array * would contain the names of the child resources
in the order provided by the resource resolver.
Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a
Hi,
Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander
Klimetschek:
On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote:
the special array * would contain the names of the child resources
in the order provided by the resource resolver.
Maybe we could just use a regular
On 07.04.11 13:31, Felix Meschberger fmesc...@adobe.com wrote:
The problem is that :order already is used by the Sling POST Servlet
to define the order of newly inserted nodes...
Ah, yes, I thought that one was named differently (should have checked
:-)).
But maybe this is ok? In all the cases I
why not just render the ordered child nodes as a json array?
On Apr 7, 2011 10:22 AM, Alexander Klimetschek aklim...@adobe.com
wrote:
On 07.04.11 13:31, Felix Meschberger fmesc...@adobe.com wrote:
The problem is that :order already is used by the Sling POST Servlet
to define the order of newly
On 07.04.11 19:38, Eric Norman eric.d.nor...@gmail.com wrote:
why not just render the ordered child nodes as a json array?
This would be much more incompatible with the existing way of using a JSON
object, and then you need to think about what the name for the special
property designated for the
On 07.04.11 20:46, Alexander Klimetschek aklim...@adobe.com wrote:
On 07.04.11 19:38, Eric Norman eric.d.nor...@gmail.com wrote:
why not just render the ordered child nodes as a json array?
This would be much more incompatible with the existing way of using a JSON
object, and then you need to
thanks felix,
i think we go the same way here - maybe it was not so clear from my wording :-)
all i'm saying is: sling uses a JSON like format to present a resource
tree which can cause problems for JSON/ECMA compliant clients that
don't implement stable child object ordering. as mentioned by [3]
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman eric.d.nor...@gmail.com wrote:
why not just render the ordered child nodes as a json array?
that's another way, yes. but then you need to transport the resource
name in a special property. eg:
{
name: foo,
properties: {
},
children: [
{
Yes, but if order is important it seems more correct to send an array. And
adding a psuedo 'order' property isn't backward compatible either.
On Thu, Apr 7, 2011 at 11:26 AM, Tobias Bocanegra tri...@adobe.com wrote:
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman eric.d.nor...@gmail.com
wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.
On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegra tri...@adobe.com wrote:
thanks
you can just add a feed.json.jsp file and use {resourcename}.feed.json
to render your custom output
HTH
Ruben
On 4/7/2011 12:47 PM, Eric Norman wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
On 07.04.11 21:47, Eric Norman eric.d.nor...@gmail.com wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.
That's what we are
hi,
the current default render servlet for JSON [0] uses the described
format. as there are already clients relying on this format, we can't
just change it. therefore adding an additional name array keeps the
format backward compatible and solves the problem.
regards, toby
[0]
21 matches
Mail list logo
