On Mon, Mar 23, 2009 at 9:16 AM, Jaroslav Pullmann
<[email protected]> wrote:
Hello,
while trying to test for the mere existence of a datamodel node it turned
out, that Data() yields to different results depending on the availability
of an immediate textual content of the node:
1) Example, path does not match, Data() is expected to return null:
<log label="NULL" expr="Data(data,'objectList/obje...@status = 1]') ==
null" />
WARNING: Data(): No nodes matching the XPath expression
"objectList/obje...@status = 1]", returning null
INFO: NULL: false
-> expected: true
<snip/>
IIRC, the reason for not returning null here is that the underlying EL
will throw its own exception if further operations (such as the
comparison above) are attempted on the null value. The type coercion
rules used are aimed at allowing simple arithmetic operations (double,
else long, else string) on leaf data nodes.
2) Example, same as 1) but tested with empty(), apparently an empty string
is returned:
<log label="NULL" expr="empty(Data(data,'objectList/obje...@status = 1]'))"
/>
WARNING: Data(): No nodes matching the XPath expression
"objectList/obje...@status = 1]", returning null
INFO: NULL: true
<snap/>
Yup.
3) Example, testing a container with no immediate textual content:
<log label="EMPTY" expr="empty(Data(data,'objectList/object'))" />
WARNING: Data(): Multiple nodes matching XPath expression
"objectList/object", returning first
INFO: EMPTY: true
<snip/>
You are correct in pointing this out, however, as mentioned above the
coercion rules were really designed for leaf data nodes (more on this
below).
4) Example, testing a leaf element with immediate textual content:
<log label="EMPTY" expr="empty(Data(data,'objectList/object/status'))" />
WARNING: Data(): Multiple nodes matching XPath expression
"objectList/object/status", returning first
INFO: EMPTY: false
<snap/>
Yes, as expected.
The method apparently invoked in this context: Object
org.apache.commons.scxml.Builtin#data()
calls SCXMLHelper#getNodeValue() to retrieve a textual representation of
the node. This is done
at the level of immediate child nodes, which themselves are not processed
recursively. According
to 1) and 3) there seems to be no test to distiguish whether a node is
missing at all or it has
element only content. For the former I'd expect null as return value,
<snip/>
At the time the decision was made, the general philosophy to avoid EL
blow ups as noted above made sense.
for
the latter all text nodes
concatenated in a deep frist traversal of all child nodes ?
<snap/>
Possibly. We've generally tried to discourage checking values of
anything other than leaf data nodes i.e. given the proposal, the
following <foo>s will be coerced to the same value, which is
differently strange :-)
<foo xmlns="">
A
<bar>B</bar>
</foo>
<foo xmlns="">
A
<otherbar>B</otherbar>
</foo>
-Rahul
Thank you
Jaro
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
