[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xsl-list
Subject:    Re: [xsl] calling template with name passed in a variable
From:       Wendell Piez <wapiez () mulberrytech ! com>
Date:       2009-12-21 17:10:55
Message-ID: 20091221121330.GA56698 () mail11c ! verio-web ! com
[Download RAW message or body]

Hi Piotr,

At 11:12 AM 12/19/2009, you wrote:
>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.

He doesn't need to know this if he doesn't need to code XSLT, true, 
but if he does, maybe he's better off knowing this. :-)

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

It would seem cleaner, yes. But it would only hide the dirt.

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

Those of us who have done it (and yes, these techniques have been 
tried) know that template matching scales very well. It's also, for 
reasons explained earlier, more robust.

So far the best argument you have given for not using the mechanism 
proposed is "it's confusing to people who don't know the language and 
can't be bothered to learn it". I admit this is sometimes a problem, 
but I'm not sure it's a problem with XSLT.

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

There are certainly ways to trap these errors besides generating a 
complile-time error in your XSLT. :-)

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

This is a creative approach. But if it were me, I admit I would just 
document how they should write the actual XSLT (which isn't that 
different, I think), and hope that they would either do that 
correctly without complaint, or be inspired to learn enough about 
XSLT that they were content with it.

There is also the remote possibility that you get a user who actually 
knows enough XSLT to be suspicious about writing new templates that 
can't possibly be called from modules they haven't written....

Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


--~------------------------------------------------------------------
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@lists.mulberrytech.com>
--~--

[prev in list] [next in list] [prev in thread] [next in thread]