Re: nested templates?

Hi Alex,

> instead, I need to be able to take a prototype:
[snip]
> and _rapidly_ construct a stylesheet from that prototype, which
> means I need to retain its correct, original structure.
[snip]
> But I prefer the idea of defining named subtemplates within a scope,
> so I can replace them at will with "included" templates. Of course
> that's only useful if you're constructing complex documents, but
> that's exactly what I'm doing.

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?

(This seems to me not unlike the stuff that Alexey Gokhberg was
talking about a while ago - locally scoped functions, lambdas, all
that stuff.)

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.

> So, the idea is to build a default 'form layout' which takes care of
> table structure, conditionally printing errors, etc - and a set of
> little includes which take care of the actual html form element
> construction:

(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'?)

> <xsl:template name="text">
> <input>
> <xsl:attribute name="type"><xsl:value-of
> select="input/type"/></xsl:attribute>
> <xsl:attribute name="size"><xsl:value-of
> select="input/size"/></xsl:attribute>
> <xsl:attribute name="maxlength"><xsl:value-of
> select="input/maxlength"/></xsl:attribute>
> <xsl:attribute name="value"><xsl:value-of
> select="input/value"/></xsl:attribute>
> </input>
> </xsl:template>

(You could simplify this to:

<xsl:template name="text">
  <input type="{input/type}" size="{input/size}"
         maxlength="{input/maxlength}" value="{input/value}" />
</xsl:template>

Attribute value templates are you friends.)

> It isn't realistic to store all of those templates inside every form
> file, and it's dumb (for reasons you probably beat me to) - so
> instead of doing that, I will include them dynamically (if I can get
> <xsl:call-template name="$variable_name"> to work correctly) based
> on the <input> definition above.

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?

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.

(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'.)

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>

Or use the two-pass solution described above to dynamically create the
stylesheet that includes the template that makes the call :)

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>

Dunno if that helps or not, but there you go.

Cheers,

Jeni

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



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