[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: calling template with name passed in a variable

Subject: Re: calling template with name passed in a variable
From: Piotr Dobrogost <pd@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 19 Dec 2009 17:12:18 +0100
Re:  calling template with name passed in a variable
On 2009-12-19 07:10, xsl-list-digest-help@xxxxxxxxxxxxxxxxxxxxxx wrote:
Date: Fri, 18 Dec 2009 16:07:54 -0500
From: "G. Ken Holman"<gkholman@xxxxxxxxxxxxxxxxxxxx>
Subject: Re:  calling template with name passed in a variable
Message-Id:<7.0.1.0.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

Well, to be able to easily refer to specific template handing some type (for instance when talking with someone) it would be nice to name these templates as well like this


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

risk that you mistype the name of a template
See 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.

Let's say someone needs to handle a new type some day. He asks me how to do this and then I would like to avoid having to explain how code that is concerned with matching and applying his new template works. He doesn't have to know this, he probably doesn't even care. I wish I could just say add your template anywhere and name it the same as the type it handles. Wouldn't that be cleaner? This example is not the best one to illustrate the above situation because matching in this case is really simple but we could imagine much more complex matching logic involving many templates not just one.


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.

I already have this kind of template but for different reason; not having special template to handle specific type is not an error. In this case specification describes what the output should be.


This approach is non-fatal. A call to a non-existent template is fatal.

As my output is a source code I prefer fatal errors to producing invalid output.


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.

I getit.


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>

I would produce the following definition

<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.

Very true and I feel guilty of doing this myself. On the bright side; I'm aware I'm doing this :)



Regards Piotr Dobrogost

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.