This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: nested templates?
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] nested templates?
- From: Alex Black <enigma at turingstudio dot com>
- Date: Thu, 17 May 2001 11:49:46 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> The way Chris (Bayes) has been talking implies that the 'nested
> templates' would be locally scoped and be applied in preference to
> 'global templates'... oh and he's talking about matching templates
> rather than named ones :) Of course we're talking about made-up syntax
> here, but I'm not sure how this would tie in with what you say about
> *replacing them* with 'included' templates. How would you include
> them? A local xsl:include?
Yeah, basically.
For elements that you want handled externally, you decide what to include,
include it, and call the template.
> Anyway, I don't think it would be too hard to write a stylesheet that
> takes a stylesheet that uses nested templates and transforms it into
> XSLT 1.0 by flattening it, adding modes to matching templates and
> namespaces to named templates so that you get the effect you're after.
> You should use a different (extension) namespace for the nested
> templates (and any other non-XSLT syntax that you introduce). This is
> the general approach that Oliver Becker used for a looping construct.
> You can submit it to the EXSLT site as an extension element if you
> don't want to think up the namespace yourself.
This irks me :)
I don't like the idea of writing something to compensate for something.
Eghfoo! Some people got into that with php sessions, and it ended up a
nightmare.
> (Your terminology of 'little includes' is a bit confusing for those of
> us that are used to using 'include' to mean including a stylesheet
> using xsl:include. It looks like you mean 'little templates'?)
No, I do mean actuall physically separate files which handle form element
construction.
Those files need to be available to all of my xsl.
> (You could simplify this to:
>
> <xsl:template name="text">
> <input type="{input/type}" size="{input/size}"
> maxlength="{input/maxlength}" value="{input/value}" />
> </xsl:template>
That works?
really?
cool!
so, can I do that with call-template and include?
<xsl:call-template name="{input/name}"></xsl:call-template>
??
must test!
thank you!
> This is where I start thinking I don't understand at all, probably
> because of terminology again :)
>
> Why are you storing templates in a form file? Isn't that the
> *source*? Shouldn't you be storing templates in a stylesheet?
I am storing those template in the form _xslt_.
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 :)
Show me the money! er, code!
> You can't dynamically include stylesheets. If you want to make sure
> that a stylesheet only contains the templates that it needs to perform
> a particular transformation, then you need a two-pass solution: the
> first to create a stylesheet that holds only the relevant templates
> (perhaps by including them with xsl:include), and the second to use
> this stylesheet to transform the source.
You _cannot_ dynamically include stylesheets?
Why on earth would that be a design feature?
That is exactly what I want, and need. I really should not have to write a
stupid php library which is responsible for getting me all the xsl I need.
> (My instinct is that this two-pass approach is likely to be less
> efficient than a one-pass approach overall, unless you're going to
> reuse the result of the first pass multiple times. I get the
> impression that you're worried that having the processor search
> through lots and lots of templates to find the one matching a
> particular node is a problem, that you're worried that the more
> templates you have, the more inefficient the code is going to be
> because the processor will be spending lots of time finding them? I
> honestly don't think that's a performance problem you should be
> worried about - in all his lists on increasing the efficiency of
> stylesheets, Mike Kay has never said 'use fewer templates'.)
This is exactly correct, and it is a performance problem, and it's also a
"hard to maintain, verbose codeset even for xsl" problem.
> You will never 'get <xsl:call-template name="$variable_name"> to work
> correctly' because it isn't possible to dynamically work out the name
> of the template that you intend to call. The only thing you can do
> is:
>
> <xsl:choose>
> <xsl:when test="$variable_name = 'foo'">
> <xsl:call-template name="foo" />
> </xsl:when>
> <xsl:when test="$variable_name = 'bar'">
> <xsl:call-template name="bar" />
> </xsl:when>
> ...
> </xsl:choose>
Oh, x-nay on my excitement above.
That is a design flaw. I should be able to do this:
<xsl:call-template name="{input/type}" />
> Or use the two-pass solution described above to dynamically create the
> stylesheet that includes the template that makes the call :)
eghgfoo.
> Ahh... it occurs to me that perhaps the reason you want to do this is
> because you need different templates for the different kinds of form
> elements, but are struggling to see how to do that when using named
> templates? It would be a lot easier for you if you used matching
> templates rather than named ones. Then you could have different
> templates for different types of input:
>
> <xsl:template match="input[type = 'text']">
> <input type="{type}" size="{size}"
> maxlength="{maxlength}" value="{value}" />
> </xsl:template>
>
> <xsl:template match="input[type = 'dependent_pulldown']">
> ...
> </xsl:template>
That is helpful, thankyou. Quite helpful, actually :)
But there is still the problem of "physically" abstracting these input
element templates so they can be included from many, many stylesheets.
And I really, really, really want to avoid using one big include for that.
> Dunno if that helps or not, but there you go.
it does, quite a lot.
thank you :)
_alex
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list