Re: nested templates?

> 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