> Then, how could you
> tell the difference between someone passing in a DOM Node and someone
> passing in an XNodeSet from the beginning?
hmmm...
(For simplicity's sake, let's assume a node right now...)
In setParameter, check instance of Node.
If so, call DTMManager#getDTMHandleFromNode, and construct an XNodeSet
from the result.
Maybe set a special flag on that XNodeSet for the purposes of
getParameter?? (So we can pass back a Node instead of a XNodeSet).
In MethodResolver#convert, in the XObject.CLASS_NODESET case, it should
fall through to the last else, and dtm.getNode(childHandle) should,
hopefully return the same node that was passed in.
If you then return that node in the function, the DTMManager should return
the same DTM handle.
It probably gets a bit more complicated with NodeLists, etc.
I'm not sure how passing in XNodeSet would be a problem. Presumably, the
XNodeSet should be set up to do the right thing?
-scott
Gary L Peskin
<garyp@firste To: [EMAIL PROTECTED]
ch.com> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Re: [Bug 2925] - Parameter set
from DOM Node, broken
07/31/01
04:57 PM
Please
respond to
xalan-dev
[EMAIL PROTECTED] wrote:
>
> > Suppose the parameter was
> > passed in with the intent that the stylesheet will pass it unscathed
> > through to an extension function. In that case, we've just hosed the
> > extension function call since we've changed the incoming parameter.
>
> Actually, I don't think so. The node should be looked up again in
DOM2DTM,
> and they should get the same node in the extension function as they
passed
> into setParameter. (Handwave over some details...)
Oh. I didn't think of this going back and forth. Then, how could you
tell the difference between someone passing in a DOM Node and someone
passing in an XNodeSet from the beginning? Suppose it's passed as an
opaque non-XSLT object to an extension function. This means there would
be no way to pass a DOM Node to an extension function via setParameter.
For example:
<xsl:stylesheet ...>
<xsl:parameter name="myNode" select="caller sets to a DOM node"/>
<xsl:template match="/">
<xsl:value-of select="java:getNodeName($myNode)" />
</xsl:template>
</xsl:stylesheet>
Would this still work with your scheme? If so, great!
Gary
>
> getParameter might be a tougher issue.
Acutally, I think these are kept separately so I think this is actually
an easier issue.
>
> > However poor
> > this coding style is, it should probably work.
>
> Nope. The contract of Xalan with the outside world is that DOMs that are
> passed in can not be mutated. The issue here lies with DOM2DTM. If we
> change this, it would be with a lot of pain.
Well, I know that's the contract with respect to the XSLT and XML
trees. I've never seen that applied to parameters. It's fine with me.
It should just be documented somewhere if it isn't already.
>
> > So, I guess in typing this email, I've come to the conclusion that the
> > best way out of this would be to provide a series of small helper
> > methods to assist the user who wants to call setParameter in converting
> > things into a XalanJ-palatable way of representing the parameter value.
>
> I hope we don't have to do this.
I just don't see how to avoid this without taking the capability away
from the caller of setParameter to pass what he/she really wants. Maybe
the caller doesn't need that capability. I'm reluctant to discard it,
thought, without more thought.
Gary
