Re: [xsl] When to use conditional constructions?

[Brian Chrisman <brchrisman@xxxxxxxxx>]

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@xxxxxxxxx> wrote:
> On Sun, Mar 30, 2014 at 1:07 AM, Dimitre Novatchev <dnovatchev@xxxxxxxxx> 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.