On Fri, Mar 21, 2014 at 4:37 PM, Andrew Welch
<andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> wrote:
On 21 March 2014 16:10, Ihe Onwuka <ihe(_dot_)onwuka(_at_)gmail(_dot_)com>
wrote:
On Fri, Mar 21, 2014 at 3:37 PM, Andrew Welch
<andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> wrote:
<xsl:template match="RentAmount | MonthlyAmounts">
<xsl:attribute name="class" select="'money'"/>
This will no doubt go down a long road but... that dangling attribute
creation there is a bad idea, as it depends on that template always
being executed directly after a start element is added to the result
tree.
Well not quite. It could be legitimately preceded by other templates
that do dangling attribute creation without a problem.
Yes it might work fine today, but if a refactoring elsewhere unrelated
to this causes some child content to be added... this will break.
It's tightly coupled to the way it's called, which is bad.
and I chose it over the other evil which is replicating the same
template code for each amount type that exists now and in the future.
Correct me if I'm wrong but couldn't you say the same thing over each
and every application of xsl:attribute-set
It's an anti-pattern.
Yes I'm sure there's another way of achieving the same thing but I'd
rather be anti-pattern than anti-declarative.
--~------------------------------------------------------------------
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>
--~--