Mark Waschkowski wrote:
"That's true, but the JCR behavior seems harmless to me" re:setting null
causes property to be removed
Actually, this caused a problem for me. I needed to represent a node in
xml,
and so created a transformation from a node to xml, but noticed early on
that if a property was set to null, my xml representation showed nothing at
all (no property name or value). This isn't acceptable when trying to
output
the state of something to the end user. So instead I had to create an
Well, that's a very absolute statement. I think it's a very natural way
to output a state.
object
from the node and then create xml output for the object instead of just
transforming the node to xml. It appears to me to be an unnecessary step
forced on me due the the api. I don't understand why setting the property
value to null would also remove the property rather than just setting the
value to null.
Because the property model doesn't allow a value of "null". So yes, the
API might be clearer if trying to set a value to null would throw an
exception.
"I strongly disagree. Being absent, and having an empty string value are
completely different things. Font instance, you can't have a "null"
attribute value in XML."
Well, I agree that having an empty string value and being absent (and
having
a null value) are all completely different things. However, I do see
removal
of the property itself as a side effect of setting the property to null.
No, it's the only effect.
Yes, 'null' doesn't really apply to attribute values, but:
1) Attributes can be empty ie. id=""
2) there IS a difference between an empty attribute and an attribute that
doesn't exist! See:
Yes. JCR properties can have the empty string as value as well or be not
there. That's exactly the same as for XML attributes.
http://mail-archives.apache.org/mod_mbox/xerces-c-dev/200105.mbox/[EMAIL PROTECTED]
I looked at this but couldn't find how this is relevant. Maybe you could
add a few sentences of explanation.
IMHO most people will, on first time use, expect that properties set to
null
are still part of the node, just empty or nullified, and I don't see the
justification for having this unintuitive 'side effect' when setting the
property to null. But I certainly have an open mind about there is some
underlying reason for this behavior!
Again, the underlying reason is the data model for properties. And I can
only guess that that wasn't chosen arbitrarily, but with compatibility
with other property models in mind.
...
Best regards, Julian
