AAS Contractor wrote:
Or maybe even use a <xsl:choose> within a generic <emphasis> template. It
may not be as efficient as seperate matching templates (Michael?) but it's
a lot easier to understand if you're updating undocumented legacy code!
Especially if the code has been updated over some years and the various
possibly matching templates are dotted all over the place and you have to
work out all the relevant priorities :-(
Sounds like you are dealing with refactoring. In which case, I would
definitely not choose an imperative approach because it is very likely
that you miss one or two cases. Using template matching (which XSLT is
all about) you make sure that your code becomes clearer and that you
eliminate current mistakes and don't introduce new ones.
Sorry if that sounds like a rant, but it just happens to be a bit of a
bugbear of mine at present.
Well, everybody has his or her own preferences in coding. But when I see
an xsl:choose in XSLT, I'd replace it with template matching (when it is
about nodes). Same as with OO programming: when you see many switch/case
or select/case statements, you know that you have to factor it out and
make them objects, making the code easier to read and less buggy
(Refactoring by Martin Fowler, page 255: Replace Conditional With
Polymorphism)
Anyway, clarity is in the eye of the beholder. What is clear for me is
not necessary clear for you, and in the case of XSLT: especially not if
you come from an imperative world.
Cheers,
-- Abel Braaksma
--~------------------------------------------------------------------
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>
--~--