commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitri Plotnikov" <>
Subject Re: JXPath expression $myDomVariable returns an empty String!
Date Sun, 18 Apr 2004 15:54:19 GMT
If you need to acquire the node itself instead of its string value, you will
need to take advantage of Pointers.  For example you can do the following:

Document node = (Document)context.getPointer(...).getNode();

Perhaps I could add a method to JXPathContext to do this exact job. The API
would look like this:

  Document node = (Document)context.selectSingleNode(...);

I would then also add:

   List list = context.selectNodes(...)

What do you think?

- Dmitri

----- Original Message ----- 
From: "Adrian Price" <>
To: <>
Sent: Thursday, April 15, 2004 5:29 PM
Subject: JXPath expression $myDomVariable returns an empty String!

> My use case is this: a JXPathContext with a custom BasicVariables
> subclass contains several variables of various types, including strings,
> integers, booleans, etc, and others of type org.w3c.dom.Document.  In
> the latter case I wish to retrieve the DOM Documents intact by
> evaluating XPath expressions of the general form: $myDomVarName.
> However, this does not work as expected because the
> org.apache.commons.jxpath.ri.model.dom.DOMNodePointer.getValue() method
> converts the resulting Node to a string by calling the private
> stringValue() method.
> This behaviour does not seem to fit with the general spirit of XPath,
> which allows you to reference raw variable values with expressions like
> $myDomVarName, or to drill into DOM node variables with expressions such
> as $myDomVarName/some/xpath/expression.  Also, since JXPath correctly
> evaluates the '$myDomVarName' portion of the latter expression as a
> node, it seems semantically inconsistent for the former expression
> type's result to be coerced to a string.  XPath provides the
> <expr>/text() and string(<expr>) functions specifically for converting
> an XPath result into string format.  The assumption that the user will
> always intend a DOM node-type result to be coerced into a string is
> erroneous.
> What was the rationale for this behaviour and what are the chances of
> getting it fixed?  (I realize that for reasons of backward compatibility
> the current behaviour may need to be retained as the default.)  As a
> stop-gap measure is there any way I can retrieve DOM-type context
> variables unaltered using a simple XPath expression?
> Any thoughts or suggestions would be gratefully received.
> Thanks,
> Adrian Price
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message