Here is what I understand about the evaluation of "xmodule:flow-attr:input",
when "input" refers to a DOM node; at least along the interesting stack trace:
- The xmodule requests the value of the input attribute from the flow-attr
module (XModuleSource.java, line 371); nothing surprising. This
FlowAttributeModule.getAttribute function will return a String object.
- This function is implemented in FlowAttributeModule's parent class,
AbstractJXPathModule; it retrieves the object passed by the flow script (namely
{input:dom}, its class is org.mozilla.javascript.NativeObject, I believe) and
uses JXPath to access the requested "input" attribute. This is in
AbstractJXPathModule.java, function getAttribute, line 105: a call to
JXPathHelper.getAttribute.
- This helper function sets up a JXPathContext with the {input:dom} context
object, and calls is getValue("input") method (line 96). This getValue function
returns a String. If on the JXPathContext instance we called
getPointer("input").getNode(), we would obtain the original DOM Node object.
This means that if the bug is not in JXPath, then it is this function call. I
know too little to tell if getPointer(name).getNode() is correct - it might
break other use cases, I don't know. Nevertheless, I can go further, though it
gets hazy.
- The call reaches the JXPathContextReferenceImpl.getValue(String
xpath,Expression expr) method, where xpath is the "input" string, and expr its
compiled version. Here comes some magic, and the very last function call in
this method is "result = ((NodePointer) result).getValue()". This getValue()
method calls the toString() of the Node inside the pointer. This is actually
documented in the Pointer interface [1].
I hope this is more than enough to figure out what's going on. I did continue
the trace in the
org.apache.commons.jxpath.ri.model.dynamic.DynamicPropertyPointer.getValue()
method and eventually got to the line where the toString() method on the Node
object is called, but I can't remember where it was, and I believe it is not
necessary to find it again.
Also, some things are going on inside JXPath; I believe objects of class
org.w3c.dom.Node are handled specially somewhere along the way. As I mentioned,
if the object is a HashMap, then JXPath returns the object itself and not the
toString() value. Node instances are considered not plain objects but part of
the tree JXPath is working on, and e.g. "flow-attr:input/elem" would similarly
work (well, I figure that's why the flow-attr module uses JXPath in the first
place).
But enough talk, I've most likely said much-much more than what is needed to
diagnose the bug. If I can be of any more assistance, I'm available and willing.
Csaba
[1]
http://jakarta.apache.org/commons/jxpath/apidocs/org/apache/commons/jxpath/Pointer.html#getValue()
> Kazó Csaba wrote:
> > Hi,
> >
> > I'm trying to get a generator to work with a DOM Node that I pass it
> > from flowscript. The method seems to be described at
> > http://cocoon.apache.org/2.1/861.daisy.html - basically I do
> > cocoon.sendPage("page",{input:dom}) in my script and
> > src="xmodule:flow-attr:input" in my generator.
> >
> > Now, this doesn't work. The exception says "The object type: class
> > java.lang.String could not be serialized to XML:".
> If you can give insight into where there may be a bug (you say
> toString() is being called somewhere?) or preferably create a patch then
> I'll be happy to commit it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
