My guess is the main difference between where you would use an
imperative style and where I would use apply/match (I rarely use
if/choose), is in whether or not you base your transformation on an
identity template.
With an identity transform as the base, all templates can be
more-or-less viewed as what would traditionally be called 'hooks' or
'handlers'.
In *most* templates, I'll want to continue processing, so I'll be
calling 'apply-templates' anyways, so I might as well encode
conditional logic into select/match/mode.
My transforms are always a series of 5-10 pipelined transformations
(generally including at least one transformation modifying a
stylesheet for subsequent application).
Those stylesheets all perform actions on the document which are
generally non-commutative (ie, A(B(source)) != B(A(source)), and I try
to combine commuting templates into the same stylesheet for efficiency
(though by nature of having all these transforms, obviously runtime
efficiency isn't generally my top priority).
I've been thinking a lot more about the style DN expresses in his
pluralsight course relating to imports and that "hybrid declarative/OO
design". It's foreign to me, as I don't think I've ever put an
xsl:import element in a transform document before, so I've probably
been missing a whole slew of functionality for over a decade. :) (On
the other hand, since I always work with identity-based transforms and
as DN's material specifies, you can't match anything imported if you
have a top level identity template, so any investigation I might have
tried in the past would probably have ended in frustration.)
I guess this is a question for DN then... is there a good way to mix
identity-based transforms with imports? I guess the identity always
has to be at the bottom of the xsl:import priority list? Or are these
types of design fundamentally incompatible?
- Brian
On Sun, Mar 30, 2014 at 5:25 AM, David Rudel <fwqhgads(_at_)gmail(_dot_)com>
wrote:
On Sun, Mar 30, 2014 at 1:07 AM, Dimitre Novatchev
<dnovatchev(_at_)gmail(_dot_)com> wrote:
This is the full proof that XSLT conditional instructions can be
eliminated in any version of XSLT.
BTW, I have quite a lot of experience writing complex transformations
without any XSLT conditional instructions. :)
Cheers,
Dimitre Novatchev
Dimitre, as typical, your posts are very insightful. I'm now wondering
how much I should consider avoiding conditionals in my own work.
This provoked a general question I have for experiences XSLT
programmers who frequently use <xsl:apply-templates> or some other
method to avoid what would normally (in a more imperative regime) be
done using conditional constructions.
Have you found that, in general, it is best to avoid conditional
constructs? If so, could you share what advantages you have found by
doing so?
Does this behavior extend to XPath's "if" statement as well, or do you
see that as a different beast? (In other words, do you find that the
advantages you obtain by avoiding XSL's conditionals do not apply as
much when considering cases that can be addressed using XPath
instead?)
Are there specific cases where conditional constructs should be
favored? (E.g., in <xsl:iterate> to allow Tail Call optimization?)
As I have confessed in the past, for my work the thing I value most
about XSLT is its support of XPath. I still tend to use imperative
programming, so my scripts tend to look like the XSLT equivalent of a
Java program that uses a single class.
-David
--
"A false conclusion, once arrived at and widely accepted is not
dislodged easily, and the less it is understood, the more tenaciously
it is held." - Cantor's Law of Preservation of Ignorance.
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--