Subject: Re: [xsl] When to use conditional constructions?|
From: Brian Chrisman <brchrisman@xxxxxxxxx>
Date: Sun, 30 Mar 2014 12:11:22 -0700
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.