[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: determine the number of payment methods and specif

Subject: RE: determine the number of payment methods and specify order depending on page type being viewed
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Tue, 4 Nov 2008 15:57:08 -0000
RE:  determine the number of payment methods and specif
> 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.                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 
> ======================================================================

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.