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

Re: nested templates?

Subject: Re: nested templates?
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Fri, 18 May 2001 08:33:07 +0100
nested call templates xslt
Hi Alex,

> so, can I do that [attribute value templates] with call-template and
> include?

No - you can use it for any attribute value on a literal result
element (i.e. the output that you're creating), but there are only a
set number of attributes on XSLT elements where you can use it, such
as the name attributes on xsl:element and xsl:attribute and most of
the attributes on xsl:sort.

> I can't attach any of this which is a little annoying, maybe I
> should actually post the xslt I am referring to, and let you see it.
>
> I find that works better than trying to explain :)

Absolutely.  Feel free.

> You _cannot_ dynamically include stylesheets?

That's right.

> Why on earth would that be a design feature?

I don't think that they advertise XSLT on the basis of it not being
able to dynamically include stylesheets.  I don't know the
technicalities, but it would make it a lot harder for processors if
they had to dynamically create the stylesheet that they were supposed
to use, based on the stylesheet that they were supposed to use.  I
*think* that dynamic includes in other programming languages tend to
come at the pre-compilation stage rather than at run-time, though
perhaps you can quote other languages where it's allowed?

> That is a design flaw. I should be able to do this:
>
> <xsl:call-template name="{input/type}" />

As I pointed out, you probably want to use matching templates rather
than named ones to achieve this effect.  I guess the reasoning behind
not allowing you to call templates where you make up the names on the
fly is that if you make up a name for a template that doesn't exist,
the stylesheet will fail.  If you know all the names in advance, then
you can use xsl:choose to choose between them.

> But there is still the problem of "physically" abstracting these
> input element templates so they can be included from many, many
> stylesheets.

You can put them in separate stylesheets and include them all into
your main stylesheet.  They would then be physically separate, but
available in lots of stylesheets.  You can have as many xsl:include
elements in your stylesheet as you like.  You can have xsl:included
stylesheets include other stylesheets.

The usual solution for people who really want to have stylesheets that
only includes the templates that you need to use for a particular
document, is to auto-generate that stylesheet based on the document;
that gets to be worthwhile if you're processing that document over and
over again.

Another solution that you might consider would be to abstract up a
level and have the definitions of the HTML that you're creating stored
in 'templates' that you have in separate files, access those files on
demand using document() and *interpret* the templates, using XSLT, to
create the output that you want.  This might be worthwhile if you have
loads and loads of these separate documents and you can specify the
output that you want relatively easily within your 'templates' so that
the interpretation that the XSLT has to do is fairly straight-forward.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 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.