David Carlisle wrote:
<xsl:variable name="contents"
select="document(string($componentFilename))//body/form/*" />
<xsl:apply-templates
select="exslt:node-set($contents)" />
you don't need a node-set extension here, (some node set extension
implemenattions would probably generate an error as they expect a result
tree fragment as argument but $contents is a node set.
so you can just use
<xsl:apply-templates select="$contents" />
which means you don't need the variable either, and canuse
<xsl:applt-templates
select="document(string($componentFilename))//body/form/*" />
Thanks. That works just fine, and is cleaner too.
As a first attempt, ignoring the stuff about replacing %CT% when there is
no tag defined, I tried modifying this template to use the str:replace
template available at www.exslt.org, but that has not worked out so well.
You need to apply the string replacement (separately) to each attribute
and text node.
You don't show the templates that are invoked by the above
apply-templates call but they need the replacement call adding, perhaps
in new temlates such as
<xsl:template match="text()">
<xsl:value-of select="str:replace(....
</xsl:template>
Sigh. I was afraid that this would be the answer. My immediate reaction
is horror,
but maybe this wouldn't be too bad to implement. I don't have too many
templates
that will get matched inside the component processing.
I would rather do this with XSLT because I can then display
a document with a browser
Browser XSLT implementations don't support exslt though do they?
(mozilla doesn't support any extensions at all)
Sorry, I always run it through xsltproc first, then feed it to the browser.
Thanks for your help.
- Rush
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--