Re: [xsl] calling template with name passed in a variable

Subject: Re: [xsl] calling template with name passed in a variable
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Dec 2009 16:07:54 -0500
At 2009-12-18 21:53 +0100, Piotr Dobrogost wrote:
Date: Fri, 18 Dec 2009 02:14:20 GMT
From: David Carlisle <davidc@xxxxxxxxx>
Subject: Re: [xsl] calling template with name passed in a variable
Message-Id: <200912180214.nBI2EKee001410@xxxxxxxxxxxxxxxxxxx>
why have a named template there?

To be able to call by template by name with template's name being equal to current value of @type.
The goal is to execute different code (have different template matched) for all xsd:elements with given @type's value from the $InPlaceTypesList list. But I would like to avoid writing by hand a separate match for each element of $InPlaceTypesList list like this;

<xsl:template match="xsd:element[@type='MyTypeX']">
  code for THIS type
<xsl:template match="xsd:element[@type='MyTypeY']">
  code for THIS type

But not only is that the right way to do it, it has half the number of times that you type the @type attribute values, and there is no risk that you mistype the name of a template

I would like be able to extend xsl easily by adding new types to InPlaceTypesList param and to add new templates handling these new types with templates' names being the same as the names of new types like this;

<xsl:param name="InPlaceTypesList" select="('MyTypeX','MyTypeY','MyNewType1','MyNewType2')"/>

<xsl:template name="MyNewType1">
  code for THIS type

<xsl:template name="MyNewType2">
  code for THIS type

I do not see how that would be any "better" than the individual matches.

Plus, you can have a catch-all along the lines of:

<xsl:template match="xsd:element[@type]" priority=".4">
<xsl:message>Missing the handling of <xsl:value-of select="@type"/></xsl:message>

... which will signal when you are missing code for the handling of a particular type. This approach is non-fatal. A call to a non-existent template is fatal.

Also, any despatching of the correct template for your matched type attribute is going to be a *lot* faster if you leave it for the processor to do the despatch than to code the despatch in the higher-level syntax. So your requested approach would also be slowing down getting the answer if it were supported.

To put this another way; I want to isolate adding templates (with purpose of handling new types) from code needed to invoke (match) them.

I see what you want to do, but not why. Are you, perhaps, simply projecting an imperative programming paradigm on top of a declarative environment because of the way you have done it with other imperative languages?

Note that the XSLT language is designed so that the processor knows all possible call requests and all possible callable templates at compile time. It can do optimization and rewriting based on this knowledge, which cannot be done if the call were dynamically resolved.

And for matching, the despatch of the template rule based on match patterns is all done behind the scenes very quickly by the processor and shouldn't be the responsibility of the stylesheet logic.

In the classroom I recognize many students trying to project the way they learned design patterns in imperative languages onto XSLT and XQuery transformations and end up thwarting opportunities for their work to run better.

I hope this is helpful.

. . . . . . . . . . . Ken

UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:
Crane Softwrights Ltd.
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:
Video overview:
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07
Legal business disclaimers:

Current Thread