On Tue, Mar 24, 2009 at 5:21 AM, Jaroslav Pullmann <[email protected]> wrote: > > Dear Rahul, > the availability of the XPathEvaluator you pointed me to [1] > provided also a solution for this use case. <snip/>
OK, good to know. Also note that for other languages it is always possible to use user-defined functions to do what you need in expressions (if the built-in Data() function isn't fulfilling your requirements). A little more on such functions at the bottom of this page: http://commons.apache.org/scxml/guide/contexts-evaluators.html -Rahul > Many thanks! > Jaro > > > > [1] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/ > > > > > > > Rahul Akolkar wrote: >> >> 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]
