Re: [xsl] Onion-skin overriding stylesheet

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

> We can customize a stylesheet with global parameters, we can have XML
> config files to be loaded as part of a transformation, so when exactly
> is it that the onion-skin overriding stylesheet is attractive for
> customization and maintenance?

When you require slightly different output for a different customer,
you can create a new entry point stylesheet and not touch the existing
transforms.

> Is the onion-skin mostly something we can use as a last resort if some
> unforeseen maintenance or customization need suddenly pops up, or is
> it often the most attractive approach to maintenance and customization
> from the beginning?

The latter.

> As far as I know, no matter what a stylesheet looks like, we can
> always import and override it in another stylesheet. But if the
> original stylesheet is mostly one big template with many xsl:for-each,
> we will have to recreate most of the original stylesheet in the
> overriding stylesheet, and that is not that attractive.

Yep, that's a very bad design.  A well written stylesheet uses
multiple fine grained match-based templates, a badly written
stylesheet has few templates and loads of xsl:for-each's, typically
along with named templates.

Taken to the extreme, you should also avoid xsl:value-of in favour of
apply-templates with a text() matching template.

> If we on the other hand use xsl:apply-templates as much as possible,
> and match the input as detailed as possible, using very many
> templates, if we use a lot of global variables even if only used once,
> etc., etc., it is possible to override many details in a stylesheet
> with just a line or two in the overriding stylesheet.
>
> Also if we have important functionality made with a lot of functions,
> we can include the logic in named templates or in xsl:function to make
> it much easier to override in the importing stylesheet.
>
> Is the onion-skin approach to stylesheet making so attractive, that we
> should make it a habit always to prepare for it, should we so to speak
> "override" optimize our stylesheets to make them as easy as possible
> to override (to maintain, to customize)?

Yes, there's no reason not to do that, it's no harder to write the
stylesheet that way and actually makes it easier to follow the
execution path.


-- 
Andrew Welch
http://andrewjwelch.com