Re: [xsl] Problem with xsl:template using XSLT 1.0

["Andrew Welch" <andrew.j.welch@xxxxxxxxx>]

On 05/12/2007, Scott Trenda <Scott.Trenda@xxxxxxxx> wrote:
> This received a lot more replies than I had initially expected. :/
>
> I gave that advice to start with because I thought it would ensure that
> he'd avoid context-dependent expressions in his match patterns. From
> what I've been reading in the replies, there seems to be a lot of
> personal coding style decisions that can lead to several different but
> functionally equivalent stylesheets in the end. Myself, I like to have
> more control over my output document, and so I only let the default
> behavior take over when I know it'll do exactly what I want. Generally
> it's as simple as starting with a root-match template and applying
> templates selectively.
>
> Could this thread die now? Seems we're kind of chasing our tails here.

There's an important design principle here though.  Because coding
XSLT is still maturing most developers will be writing code from
scratch rather than maintaining old code.  As the amount of XSLT grows
maintainability will become an issue.

Given a stylesheet and the task of modifying its behaviour, if the
stylesheet has been written in a certain way you can simply import it
and override the appropriate template, without needing to modify the
original stylesheet.

If the code is hidden within a template, then you either replicate the
whole template and change you part you need, or modify the original.

Most of the XSLT I've written takes the form of at least one
"common.xslt"and then a number of specific stylesheets for each
variation import common:

specific1
specific2

etc

and even then I've had requirements to modify a specifc stylesheet
because one customer wants exactly the same as another customer, but
with minor changes.  This is a 2 minute job with the right structure.

What I've learnt over the years of implementing this pattern over and
over again is that in common.xslt, and even the specific stylesheets,
is to code to allow behaviour to be overridden.  The amount of times
I've had to go back and rewrite templates in common so it calls
templates instead of just outputting code... the most basic form is:

<img src="logo.gif"/>

becomes:

<xsl:call-template name="logo"/>

...where the "logo" named template only exists in the specific stylesheets.

If everything is done right, adding support for a new customer is just
a case of adding a new stylesheet containing just the code specific to
them.

This is why I like the idea of the no-op templates, as it gives you a
chance to override the behaviour.

cheers
-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/