Subject: Re: [xsl] calling template with name passed in a variable|
From: Piotr Dobrogost <pd@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 19 Dec 2009 17:12:18 +0100
Date: Fri, 18 Dec 2009 16:07:54 -0500 From: "G. Ken Holman"<gkholman@xxxxxxxxxxxxxxxxxxxx> Subject: Re: [xsl] calling template with name passed in a variable Message-Id:<188.8.131.52.2.20091218155645.0298df38@xxxxxxxxxxxxxxxxxxxxxx>
At 2009-12-18 21:53 +0100, Piotr Dobrogost wrote:
><xsl:template match="xsd:element[@type='MyTypeX']"> > code for THIS type ></xsl:template> >.... ><xsl:template match="xsd:element[@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
<xsl:template name='MyTypeY' match="xsd:element[@type='MyTypeY']"> code for THIS type </xsl:template>
risk that you mistype the name of a templateSee fatal/non-fatal note below.
>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;
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> </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.
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.
Ok. In this case it looks like I would have to first generate new xsl based on the original xsl and then execute this new one. For example having this definition in the original xsl (possibly added my someone else)
<xsl:template name="MyNewType1"> code for THIS type </xsl:template>
<xsl:template match="xsd:element[@type='MyNewType1']"> <xsl:call-template name="MyNewType1/> </xsl:template>
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.
Regards Piotr Dobrogost