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: Thu, 15 Feb 2001 13:04:29 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Thu, 15 Feb 2001, Dimitre Novatchev wrote:
> > In the past I've considered doing this in Saxon. But I'm undecided whether
> > the attribute value should be an AVT (therefore always yielding a string) or
> > an XPath expression (in which case any value can be passed, but strings need
> > to be written in double-nested quotes, e.g. arg="'London'"). Any views?
> >
>
> Obviously, only the latter will make it possible to substitute any
> xsl:call-template with xf:func.
As pointed out by Steve Muench, the attribute version will
not be able to pass result fragments. However, a slightly
modified version using "elements" will do the trick...
<xf:func one="xpath" /> <xsl:call-template name="func">
becomes <xsl:with-param name="one"
select="xpath" />
</xsl:call-template>
<xf:func one="xpath" > <xsl:call-template name="func">
<two> <xsl:with-param name="one"
<res>frag</res> becomes select="xpath" />
</two> <xsl:with-param name="two">
</xf:func> <res>frag</res>
</xsl:with-param>
</xsl:call-template>
Clearly, the attribute-only version is much cleaner. However,
the element syntax below could be used for those times when a
result fragment must be passed... I'm not sure I like it though.
> > (Though actually, I've also held off because I'm reluctant to implement
> > non-portable extensions if they provide nothing more than a saving in
> > keystrokes ...)
>
> They provide far more than saving in keystrokes... Consider the
> improved readability, understandability and therefore reliability
> of the code. Consider also the cost savings in code
> maintenance. And the ability to enter more code in less time... :o)))
>
> Some mathematicians argue, that whole new disciplines appeared or
> were significantly influenced by the appearance of new, better
> notation. xsl:call-template is clearly far from the optimal notation
> possible.
Neat. The choice as to what is in-lined and what is made into
a seperate template is largely based (in my case) upon the
difficulty required to setup a seperate template and call
the template. In my experience, when this pain can be
lessened... then better modulization will be the result.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list