Now it happens that the fact that you're generating the
results in a fixed order actually simplifies things for you.
Your 'class'
attributes can each be one of three values, "doubleLine
completed", "doubleLine current" and "doubleLine". But
because the elements will come in order, these do not map
arbitrarily. Actually it's something like this:
Good work Wendell, and congratulations on your patience. I spent a few
minutes on this and gave it up: somehow it the ratio of complexity and
tedium didn't inspire me to work on it. But you've broken the back of it.
Now it just needs a way to generify it a bit more.
How about a two-pass solution?
<xsl:template match="paymentMethods">
<xsl:variable name="temp">
<xsl:apply-templates select="directDebit"/>
<xsl:apply-templates select="creditCard"/>
<xsl:apply-templates select="invoice"/>
</xsl:variable>
<xsl:apply-templates select="$temp/*" mode="add-class"
</xsl:template>
<xsl:template match="directDebit">
<directDebit>Payment by <br/>Direct Debit</directDebit>
</xsl:template>
<xsl:template match="creditCard">
<creditCard>Payment by <br/>Credit Card</creditCard>
</xsl:template>
<xsl:template match="invoice">
<invoice>Payment by <br/>Invoice</invoice>
</xsl:template>
<xsl:template match="*" mode="add-class">
<xsl:variable name="status">
<xsl:choose>
<xsl:when test="$label = local-name()">current</xsl:when>
<xsl:when test="preceding-sibling::*[local-name() =
$label]">completed</xsl:when>
<xsl:otherwise/>
</xsl:choose>
</xsl:variable>
<li class="doubleLine {$status}"><xsl:copy-of select="node()"/></li>
</xsl:template>
Probably doesn't save many lines of code, and it runs into the 1.0
node-set() restriction, but it strikes me as capturing the logic of the
problem a bit better: if a fourth and fifth kind of payment were added,
fewer changes would be needed, as the final template has no knowledge of the
different kinds of payment.
Michael Kay
http://www.saxonica.com/
... I won't try to explain the logic of the assignment of
values to $status in each case. You should examine and test
it to be sure I'm right. (The logic assumes that only three
values are possible.)
But it's worth noticing I use XSLT "attribute value syntax" (the { }
syntax) to get this value into the li/@class attribute.
Cosmetically, if you don't like the extra space you get on
the @class when $status has no value, you can write around
that like this:
<xsl:variable name="status">
<xsl:if test="$label = 'directDebit'"> current</xsl:if>
</xsl:variable>
<li class="doubleLine{$status}">Payment by <br/>Direct Debit</li>
The other concern here is to make sure that $label is
available as a global parameter or variable; you said it was
set at run time, so I assume it is.
I think this handles your problem, except for one exception.
What happens if $label is set to 'creditCard', say, but you
have no 'creditCard' element? Currently, the stylesheet will generate:
<ul>
<li class="doubleLine completed">Payment by <br/>Direct Debit</li>
<li class="doubleLine">Payment by <br/>Invoice</li> </ul>
If your system does not have a way of preventing this from
happening, you need to think about what you want the
stylesheet to do if (when) it does.
Finally -- notice that you don't need to test to see how many
and which element children of 'paymentMethod' are present.
Instead, this work is simply done by processing the input
data: elements not present are not processed. :-) This is far
more robust, and reflects the way XSLT is intended to work.
If you need to dive in and learn how to apply and match
templates in order to get this going -- so much the better.
You'll never understand XSLT without this capability.
Template matching and the idea of "tree traversal" (context
nodes, child elements, etc. etc.) are at the heart of the language.
Finally -- I have used XSLT 1.0 methods and idioms
throughout. In XSLT 2.0, there are ways of making this more
concise (and possibly opaque). But there's little point in
doing this in XSLT 2.0 unless you can do it in XSLT 1.0
(which is arguably not true of all XSLT problems).
Please ask any followup questions for clarification.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML
and XML
======================================================================
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--