JXPath expression $myDomVariable returns an empty String!

[Adrian Price <ad...@btinternet.com>]

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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: JXPath expression $myDomVariable returns an empty String!

[Dmitri Plotnikov <dm...@apache.org>]

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" <ad...@btinternet.com>
To: <co...@jakarta.apache.org>
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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org