Hi,
I tend to favor XSLT logic over XPath logic -- not always but mostly
-- but I almost never use xsl:choose in favor of templates.
Most of the places where I use xsl:choose, it's because I have
grouping or something else going on that prohibits me from using the
implicit conditionality of templates to handle the contingencies.
I find this makes for code that is easier to refactor (at least as
soon as its complexity is more than trivial), and indeed easier to
understand at a glance -- once I understand that this is the way
xsl:apply-templates is being used.
Plus, start down this path and you find all kinds of amazing shortcuts
branch off from it.
For example, I don't bother to ask, when processing a cross-reference,
what "type" of cross-reference it is, if that is closely bound (as it
almost always is) to the type of its target. I just go process the
target.
I also use xsl:for-each as a quasi-conditional more often than I do as
a way to avoid a template. For example, instead of
<xsl:if test="exists(@class)">
<xsl:attribute name="type">
<xsl:value-of select="@class"/>
</xsl:attribute>
</xsl:if>
say
<xsl:for-each select="@class">
<xsl:attribute name="type">
<xsl:value-of select="."/>
</xsl:attribute>
</xsl:for-each>
if I don't want to bother with xsl:apply-templates select="@class",
with the template to match.
Cheers, Wendell
On Sun, Mar 30, 2014 at 8: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>
--~--
--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^
--~------------------------------------------------------------------
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>
--~--