[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: syntax sugar for call-template

Subject: Re: RE: syntax sugar for call-template
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Fri, 16 Feb 2001 09:32:43 -0700
template function syntax
> David Carlisle wrote:
> > Howver This is still an element and so still not usable in XPath
> > expressions, so I'd rather have
> >
> > ... something...
> >
> > and then have 
> > select="my:func(xpath)"
> >  essentially doing something equivalent to
> > <xsl:variable name="x"><xf:func one="xpath" /></xsl:variable> ...
> > select="$x"
> 
> Couldn't agree more strongly.  Thinking about Uche's comments on
> run-time dynamism and introspection yesterday (I don't know what that
> means but it sure sounds good) another option would be single new XSLT
> function:

introspection is in short the ability to query an object for its metadata.  
For example.  An example of metadata of a named template might be the 
parameters it expects.  Metadata on a stylesheet might be the templates it 
provides.

I do like yours and David's ideas in this area.

>   call-template('my:func', 'one', xpath,
>                            'two', $rtf)
> 
> I don't know whether this would be more or less acceptable than a
> means of defining XSLT user extension functions?  The one big
> limitation is that you wouldn't be able to return node sets (aside
> from those constructed as an RTF) so there would be limitations on
> this.

This is pretty much meta-programming: building up the construct on the fly.  
It requires dynamicism, and in many cases, introspection.

Imagine being able to automatically assign items in a node-set to the 
corresponding positional parameters in a template (with position being 
determined by the document order of the with-param elements in the template).

> Even without a general call-template() function, if we're going for
> XSLT user extension functions there's still the issue of how the
> parameters are passed.  In saxon:function, they're passed by position.
> Another alternative would be, as above, if they were passed by name
> using something like:
> 
>   my:func('one', xpath, 'two', $rtf)
> 
> rather than:
> 
>   my:func(xpath, $rtf)
> 
> I like being able to set parameters by name.  It also might lead to
> interesting situations if you dynamically alter the names of the
> parameters (they're just strings, after all) [if we had a
> call-template() function then you could dynamically alter the name of
> the template too!)

Yes.  This allows such useful techniques as delegation,  where, say a named 
template could dynamically find and dispatch to another template specialized 
to handle the needed function.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.