Altova Mailing List Archives

RE: [xsl] determine the number of payment methods and specify order depending on page type being viewed

From: "Michael Kay" <mike@------------>
Date: 11/4/2008 3:58:00 PM
> 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:apply-templates select="$temp/*" mode="add-class"

<xsl:template match="directDebit">
  <directDebit>Payment by <br/>Direct Debit</directDebit> 

<xsl:template match="creditCard">
  <creditCard>Payment by <br/>Credit Card</creditCard> 

<xsl:template match="invoice">
  <invoice>Payment by <br/>Invoice</invoice> 

<xsl:template match="*" mode="add-class">
  <xsl:variable name="status">
      <xsl:when test="$label = local-name()">current</xsl:when>
      <xsl:when test="preceding-sibling::*[local-name() =
  <li class="doubleLine {$status}"><xsl:copy-of select="node()"/></li>
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

> ... 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@xxxxxxxxxxxxxxxx
> Mulberry Technologies, Inc.      
> 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 
> ======================================================================


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.