Re: [xsl] xslt style

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Hi Simon,

> On Thursday, January 09, 2003 5:51 PM, Jeni Tennison wrote:
>> But to answer your more general question, you're correct that in
>> unextended XSLT 1.0 you have to call templates to perform functions
>> and that sometimes this can lead to verbose and ungainly code.
>> However, most XSLT processors have a mechanism for defining
>> extension functions. Several support EXSLT's
>> func:function/func:result elements, which enable you to do:
>
> Correct me if I'm wrong, or restarting an ancient debate, but it
> strikes me that using XSLT in this way is basically "Wrong" or a Bad
> Thing. I've found that usually there is a fairly simple way to avoid
> procedural techniques if I conceptualize the program as being the
> XML data, and think of it as the data making calls on the XSLT. In
> other words, in writing XSLT I'm basically writing functions that
> are called by the data, as the processor walks the tree. As far as
> XSLT being very verbose, I haven't really found that to be true yet
> either.

When I read this, I thought that you were saying that calling
templates and functions by name was a bad approach and that it's
better to use the node-matching aspects of XSLT when writing your
stylesheets. That, I can generally agree with; personally, I think
that the only time you should use named templates is when the context
node, position and size has no influence on the result of the template
-- in other words when it's a pure function that computes its results
based purely on the parameters that are passed to it. Otherwise, my
preference is to use moded matching templates.

But then I looked at what you were doing in your code, where you have
a lot of calling of named templates which rely on information from the
dynamic context, so obviously you don't view that as bad style or
"procedural code".

The other thing that you might be referring to as being better
practice is the concept of passing in parameters to templates and
functions rather than reconstructing the values that you would have
passed in based on the current node. For example:

   <xsl:template name="radio">
     <input type="radio">
       <xsl:attribute name="name">
           <xsl:call-template name="namesAttrsOfAncestors"/>
       </xsl:attribute>
       <xsl:attribute name="value">
         <xsl:value-of select="."/>
       </xsl:attribute>
     </input>
   </xsl:template>

   <xsl:template name="namesAttrsOfAncestors">
     <xsl:for-each
           select="ancestor-or-self::*[self::element or
self::attribute][@name]/@name">
       <xsl:value-of select="."/><xsl:text>.</xsl:text>
     </xsl:for-each>
   </xsl:template>

I agree that this is a good way to think: gather the information that
you can from where you are rather than storing that information and
passing it in. It's an insight that a lot of newcomers to XSLT,
especially those from a procedural background, have a hard time
gaining.

However, it does have its downsides, which you've already encountered
in your problems with the <ref> element. When you start jumping around
the tree then you lose the ability to use the ancestor axis to get
information about what-were-the-ancestors-at-the-ref. At that point
you *have* to start passing information into templates using
parameters.

The other, probably less important, downside of reconstructing
information from the current node is that performance suffers when you
try to reconstruct everything by walking the tree each time you need
to get information because it means a lot of repeated (unnecessary)
node visits. I know that I suffer from premature optimisation and
arguably my XSLT suffers with it.

Is this what you mean by "procedural code" or is it something else
that sticks in your craw? Perhaps you can give some examples of good
and bad style?

In the end, as Mike's pointed out, none of these matters of style
actually undermine the fundamentally declarative nature of XSLT. It's
the people who use disable-output-escaping that we really have to look
out for!

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list