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: Sun, 18 Feb 2001 20:56:23 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Sun, 18 Feb 2001, David Carlisle wrote:
> I do not like the idea of "return" inside a "template", I was
> only after an abbreviated method to call templates from within
> other templates; not call templates from within a xpath expr.
>
> Maybe I lost the thread of this thread but I thought your suggested
> short form was exactly calling the template using xpath extension
> function syntax?
I was just suggesting that there be a "xf" namespace
such that:
<xf:func arg="val" /> is treated as <xsl:call-template
name="func">
<xsl:with-param
name="arg"
select="val" />
</xsl:call-template>
This would make for a very simple syntax for calling a
template with within another template. And this syntax
can easily be implemented using XSLT 1.0 using a stylesheet.
> If I had a need for calling a method from within XPath, then
> I *do* like your suggestion about a seperate "function" declaration
> for creating functions callable from Xpath. It makes sense
> to have it a seperate construct for the reasons I believe
> you pointed out:
> ....
> different from the 'template requirements; and as such
> they should be seperate constructs. I belive this is your
> position isn't it? IMHO, trying to merge them will be
> FAQ heaven....
>
> Oh so basic agreement around then on this point, it seems.
There are two seperate items:
(a) making a way to define 'xpath' functions
from within XSLT (thus it must be a function
and support boolean, string, node-set, and
number data types)
(b) a less verbose call-template syntax
I'm after the latter, while it appears many on this list
are designing the former.
;) Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list