At 2009-12-18 21:53 +0100, Piotr Dobrogost wrote:
Date: Fri, 18 Dec 2009 02:14:20 GMT
From: David Carlisle <davidc(_at_)nag(_dot_)co(_dot_)uk>
Subject: Re: [xsl] calling template with name passed in a variable
Message-Id:
<200912180214(_dot_)nBI2EKee001410(_at_)edinburgh(_dot_)nag(_dot_)co(_dot_)uk>
...
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[(_at_)type='MyTypeX']">
code for THIS type
</xsl:template>
....
<xsl:template match="xsd:element[(_at_)type='MyTypeY']">
code for THIS type
</xsl:template>
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>
<xsl:template name="MyNewType2">
code for THIS type
</xsl:template>
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[(_at_)type]" priority=".4">
<xsl:message>Missing the handling of <xsl:value-of
select="@type"/></xsl:message>
</xsl:template>
... 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 http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training: San Carlos, California 2010-04-26/30
Vote for your XML training: http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--