Scott --
I fear that John has discovered a case here which highlights the
troublesome aspect of restricted interoperability between the DOM and
DTM models. He's trying to pass a DOM node into XalanJ as a parameter
for use later in the select attribute of an xsl:copy-of element.
Unfortunately, XalanJ does not know from DOM nodes in this context since
it expects such things to look like DTMs or DTM nodes.
I thought it might be a good idea in TransformerImpl.setParameter(name,
value) to convert a Node, Document, DocumentFragment, NodeIterator,
NodeSet and anything else we could think of into the appropriate DTM
construct so that we could use it later without problems in XalanJ.
However, this can cause another problem. 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.
And, it would be bad to keep around two values -- one for XalanJ and one
for extensions.
Furthermore, what would we do about the case where someone passed in a
Node as a parameter and then, after calling setParameter, decided to add
child elements or attributes or something to the node. However poor
this coding style is, it should probably work.
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.
The helper methods could be either in TransformerImpl or they could be
static methods in some other class. I thought about suggesting XObject
but I think this would undesirably couple the XPath stuff with the Xalan
stuff. The workaround shown in bugzilla works but is pretty
non-intuitive to all but the most sophisticated user (ie the
developers). So, it seems like I'm suggesting the creation of a new
class with a single static method like makeParameter(Transformer,
Object). It would cast the first argument to a TransformerImpl and then
perform a series of instanceof tests on the second argument and make the
appropriate XObject. makeParameter could either call
Transformer.setParameter() or return an XObject and let the caller call
Transformer.setParameter(). I guess I vote for option one in this
regard.
I noticed that some similar code was commented out of the static
create() method in XObject and that is probably a good thing.
What do you think?
Gary
[EMAIL PROTECTED] wrote:
>
> PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
> ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
> AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
> DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
> BE LOST SOMEWHERE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2925
>
> *** shadow/2925 Tue Jul 31 10:08:16 2001
> --- shadow/2925.tmp.15827 Tue Jul 31 11:56:01 2001
> ***************
> *** 36,38 ****
> --- 36,58 ----
> ------- Additional Comments From [EMAIL PROTECTED] 2001-07-31 10:08
>-------
> Created an attachment (id=376)
> The Program
> +
> +
> + ------- Additional Comments From [EMAIL PROTECTED] 2001-07-31 11:56 -------
> + John --
> +
> + The solution with the current code is to replace
> + m_Transformer.setParameter("stylesheets",e);
> + with
> + DTMManager dtmM = ((TransformerImpl) m_Transformer).getXPathContext();
> + XNodeSet xns = new XNodeSet(dtmM.getDTMHandleFromNode(e), dtmM);
> + m_Transformer.setParameter("stylesheets", xns);
> +
> + For this, you'll need to add the following imports:
> + import org.apache.xpath.objects.XNodeSet;
> + import org.apache.xml.dtm.DTMManager;
> + import org.apache.xalan.transformer.TransformerImpl;
> +
> + Please see my followup message to Scott regarding some of these issues.
> +
> + Gary
