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
--~------------------------------------------------------------------
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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--