See below... -JG
You should also be concerned about the possiblity of out-of-order evaluation, unless your extension code is completely taking over evaluation of that subtree. Xalan doesn't _currently_ reorder stylesheets, as far as I
Do you mean reorder templates ?
I plan to use the same mechanism that the redirect Extension Element uses to execute child templates. So I am assuming that if I have the following XSL
<xsl:template match="/">
<myExt:email>
<xsl:apply-templates select="to" />
<xsl:apply-templates select="from" />
<xsl:apply-templates select="body" />
</myExt:email>
</xsl:template>
<xsl:template match="to">
<myExt:to>
<xsl:value-of select="." />
</myExt:to>
</xsl:template match="to">
Templates from & body are the same.
The <myExt:Email> will be evaluated first and since the extension element <myExt:Email>
calls executeChildTemplates, the to/from/body will all be evaluated after and as children
of myExt:email.
With that said, I am also assuming that the order that the to/from/body templates may be evaluated as a function of executeChildTemplates may be different if Xalan was to reorder templates.
extension to extension. That also avoids any multitasking issues since each executing stylesheet has its own variable stack. I grant that it's a bit ugly, though.
It seems that an extension element can only get a parameter and not set one. So I could create a parameter as a global, or as a local as long as it is passed along with all the apply-templates, then fetch that parameter from the current extension element as some kind of mutex between extension element calls. Just
thinking out loud here.
This leads into my original question about instance control of Extension Elements.
Is there a separate method cache on a per stylesheet, per thread instance. i.e.
The same template instance that produces two transformers on two threads, will it create two separate instances of a declared extension element. If this is true, then don't need the stylesheet parameter and I can maintain control using class variables.
This differs greatly from Extensions because an extension instance becomes a parameter and you can have many separate instances, per Transformer, not just stylesheet / template.
If you're willing to risk reordering... I *think* the SQL Extension has dealt with the threadsafety issue, but I don't remember how offhand. Might be worth checking that code.
I did not code anything specifically into the SQL extension to handle thread safety.
I think because each query/pquery becomes its own variable in a Transformer, thread
safety within Stylesheets is not an issue.
______________________________________ Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- -------------------------------------- John Gentilin Eye Catching Solutions Inc. 18314 Carlwyn Drive Castro Valley CA 94546
Contact Info [EMAIL PROTECTED] Ca Office 1-510-881-4821 NJ Office 1-732-422-4917
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
