Re: [xsl] Getting variable yet most immediate parentNode

Subject: Re: [xsl] Getting variable yet most immediate parentNode
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Fri, 28 Sep 2007 19:33:59 +0200
David Carlisle wrote:
me>(@value,@name,.)[1]

wendell> ... and in XPath 1.0, you're forced into explicit testing, since wendell> attributes have no order in the data model.


or, if you must, (@value|@name[not(../@value)]|.)[last()] but perhaps's
that's "explicit testing". How explicit does something have to be to be
"explicit"?

And I always found XSLT 1.0 too verbose... this is nice and compact David!


But when this list of options gets longer, it might be better to add normal template matching and make the precedence explicit:

<xsl:apply-templates select="." mode="option-value" />
.......

<xsl:template match="option[@highervalue]" mode="option-value" priority="20">
<xsl:value-of select="@highervalue" />
</xsl:template>


<xsl:template match="option[@value]" mode="option-value" priority="10">
   <xsl:value-of select="@value" />
</xsl:template>

<xsl:template match="option[@name]" mode="option-value" >
   <xsl:value-of select="@name" />
</xsl:template>

<xsl:template match="option" mode="option-value">
   <xsl:value-of select="." />
</xsl:template>


The last two do not need a priority (generic match always has lower priority over a match with a predicate). Though this is by far more verbose then David statement, when you plan to add more and more xsl:if statements it will get messy (as you can see in your original post), using template matching you can keep the structure easy (i.e., not too nested) and you can focus on the rules instead of all possible scenarios. The scenarios are then automatically taken and chosen by the processor.


The nice thing, also, is how easy and clear it gets now for applying different styles (colors, fonts) to each of the options.

Cheers,
-- Abel Braaksma

Current Thread