This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: syntax sugar for call-template
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] RE: syntax sugar for call-template
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Sat, 17 Feb 2001 12:39:00 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Fri, 16 Feb 2001, David Carlisle wrote:
> because if you introduce a system for binding XSLT written code to Xpath
> functions that _only_ does simple cases eg, not cope with qnames as
> function names or node sets as argumnements, then you may find your
> options are severly limited when you come to specify the "full job"
> if you have to keep compatible with a half way solution that has been
> added earlier.
David, thank you for your reply.
I'm proposing this beacuse I have some 30+ stylesheets
in the work that I'm doing. And they are quickly becoming
un-manageable. More importantly, I'm duplicating "template
fragments" that are very common since the overhead for
splitting this into a callable template is so brutal. This
leads to bad modulization. I need (ok, have implemented) a
simple mechanism which is *syntax sugar* for calling templates
that can be used with existing XSLT via a meta-stylesheet.
Thank you for pointing out the "qname" limitation. This is
interesting, beacuse I've never used qnames as template names.
And, I don't see very many examples out there that do. So...
I see this as an esoteric case. I consider myself a heavy
XSLT user and I don't need them. Now. XSLT may need a nice
"packaging" mechanism. However, I hardly feel that qnames will
make my life any easier. For now, for those concerned with
name collisions, just use a "dnsname" like "func.clarkevans.com"
The chance of a name collision here is, well, infinitesmal.
Your other limitation, is that you can't call the code
through XPath. This is not a problem that I need to be
solved. Most of my XPath expressions are rather simple
already, calling templates from XPath is also esoteric.
Even so, I can call the template, return the results,
stuff the result fragment into a variable and call
an extension function to-nodeset to make the information
available via XPath. This isn't simple, but it is very
understandable...
Your final limitation is that I can't pass node-sets as
arguments. My current solution does not have this problem:
<xf:func one="xpath" /> <xsl:call-template name="func">
becomes <xsl:with-param name="one"
select="xpath" />
</xsl:call-template>
In short, I hardly see why this simple solution is
"severly limiting". It may not cover every case in which
people may want to do such a thing... but this isn't
the goal. The goal is to help template modulization
with *existing and future* XSLT processors. Nothing more,
nothing less.
Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list