[EMAIL PROTECTED] wrote:
>
> > 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).
Like I said, I think the original parameter is saved off inside an
XObject in m_userParams which is separate from the VarStack used for the
actual storage so I think this would be okay.
>
> 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?
Here's how it's a problem. In my example stylesheet below, would the
extension mechanism call Node.getNodeValue() which would be the correct
thing to do or XNodeSet.getNodeValue() which doesn't exist. How would
it know which to call?
Gary
>
>
>
> [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
