[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] When to use conditional constructions?


Subject: Re: [xsl] When to use conditional constructions?
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Mon, 31 Mar 2014 18:22:22 +0100

On Mon, Mar 31, 2014 at 4:14 PM, Wendell Piez <wapiez@xxxxxxxxxxxxxxx> wrote:
> 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.
>

+1

>
> 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.
>

Yup. There are multiple benefits. It localizes the scope of concern if
you need to implement a change and the killer argument - it localizes
the scope of what you should test following a change.

If you write your code such that each and every template has no
external dependencies this is a very resonant argument because you can
treat the template as a discrete stand-alone unit for testing
purposes. If you do not do this then the argument is less resonant but
you have bigger problems to worry about.

If you have a multi branch choose, say with 10 branches and you change
something well the entire unit has changed hasn't it. So you've just
widened the scope of concern for what you should do to test it. Note I
said SHOULD. You may well decide not to but you have taken on a risk
of not testing something that you should test. When you widen the
scope of what you need to test you widen the scope of what could go
wrong.

Additionally alot of xsl:choosing suggests one may have to mentally
track the path to a given point in code. Something you don't have to
worry about if using templates. All you have to do is ensure that the
right template fires at the right time and once it fires it does what
it is supposed to. Essentially you can treat the template as a
decoupled unit for testing and maintenance purposes if you refrain
from the evil of globals and unnecessarily tightly coupled
dependencies.


Current Thread
Keywords