hi david
note: there is twice the key "toast". as far as i understand json, this
is not valid. the php function json_decode just overwrites the property
"toast" => "bar" with the node array "toast" => array(). javascript json
parsers tend to do the same.
is jackrabbit using a custom json parser that can handle same-name keys?
jackrabbit has a custom json parser.
are there any plans to make this valid json?
no... not at the moment as same name property and node are
not properly supported by the jcr remoting anyway (see also JCR-1616)
or would the jcr spec forbid it? found nothing about it. when looking at
the xml representation, it sounds totally normal. when outputting i.e.
the path of the property and the node it looks strange.
thanks for input,
imo the same-name-property-node feature was a bad move in jsr 283
and i don't see a particular value in having this feature.
some time ago i was chatting with julian about possibilities
to distinguish properties and nodes in the jcr-remoting but
we never really invested sufficient time to address this.
as far as jsop is concerned i don't remember that we ever
talked about this problematic. but you may come up with a
suggestion on how to address this.
without a having a closer look i can think of
a - no supported at all (there is an repository descriptor for
this called: OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED)
-> fix jcr-server not to return this descriptor and not
to allow for same-named node/property siblings
b - supported by ignore the fact that it isn't valid json
c - invent some extra marker for properties that have the same
name as a sibling node.
and there are for sure many other options if this really turns out
to be a problem.
b was for free, a was rather cheap. right now with all the
jackrabbit3 effort i wouldn't invest a lot of time in c.
but it's definitely worth to keep this in mind for later
JSOP discussions in order not to forget to address this once
we have a more formal and finalized protocol.
regards
angela
david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9XuHIACgkQqBnXnqWBgIss8QCgvUFwzFLURDtdRSXHrdrboCuu
AwIAoMNJSL0VwGfjxfDJy6c87k/5gbj5
=fe9h
-----END PGP SIGNATURE-----
