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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
