[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Modes (was RE: [xsl] Re: Keys, IDs lookup tables.)


Subject: Re: [xsl] Modes (was RE: [xsl] Re: Keys, IDs lookup tables.)
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 11 Jun 2012 13:19:20 -0400

Michele,

In the example you asked about (the code I mocked up for Daniel), I used
a mode when applying templates to "ancestor::financials/perioddate/
period" not because I absolutely had to (it might have worked as well
without the mode depending on what else was or wasn't happening), but
just to avoid and forestall difficulties in case it was necessary.

I guessed it might be necessary mainly because I was processing the
element for a purpose other than the plain-vanilla ordinary reason,
namely to display its contents. In this case, the 'period' element was
being used only as a kind of scaffolding for generating output for
another element (the one passed in as the $fgroup parameter). Just in
case 'period' elements were also due to be processed in a more normal
way (presumably with a template not assigned to a mode), using a mode
here seemed prudent.

That being said, there isn't any one single thing modes are used for. On
the contrary, many neat solutions to hard problems will use templates --
which have to be put into modes so they do not conflict with other
templates matching the same nodes for other reasons.

So the mode turns up not because we are "using a mode" so much as
because we're "using a template" (or family of templates), and the mode
keeps it or them under control and out of the way.

Cheers,
Wendell

On Mon, Jun 11, 2012 at 5:01 PM, Michele R Combs<mrrothen@xxxxxxx>
wrote:
I notice that you're using "mode" in this solution.  Can someone
point me to a good explanation of modes, with good examples?  I
haven't worked much with them and am finding them a bit confusing.

Thanks

Michele

On Wed, Jun 6, 2012 at 6:04 PM, Wendell
Piez<wapiez@xxxxxxxxxxxxxxxx>  wrote:
Daniel,


On 6/6/2012 3:31 PM, daniel whitney wrote:

OK so I came up with a solution for Part 2 of my question. Not sure if it's the ideal, but it works:

Would Part 1 have a similar solution? Would I store the
"lookup" portion in a global variable and just call that again
and again?


Basically, yes, although you will get closer to your ideal of
clarity, grace and maintainability if you refactor with
templates. When doing so, you can pass parameters to retain
context.

So something like:

<xsl:template match="financialgroup">

<tr> <td> <xsl:value-of select="key('legend',
@financiallegendcode)"/> </td> <xsl:apply-templates
select="ancestor::financials/perioddate/period"
mode="period-cell"> <xsl:with-param name="fgroup" select="."/>
</xsl:apply-templates> </tr> </xsl:template>

... and to receive the call:

<xsl:template match="period" mode="period-cell"> <xsl:param
name="fgroup" as="element(financialgroup)"/>

<xsl:variable name="idBase" select="@id"/> <td> <xsl:value-of
select="($fgroup/financial[@periodref=$idBase],'....')[1]"/>
</td> </xsl:template>

Obviously the details aren't worked out here, and note also I'm
using an XPath 2.0 idiom to provide the fallback value when the
particular 'financialgroup' element has no 'financial' value for
the period.

This also fixes a bug in your code where every period covered is
 assigned all values for all of them (or the first of them, if
run as XSLT 1.0).

I hope this helps, Wendell


<xsl:template match="financialgroup">  <xsl:variable
name="currentFinancial" select="financial"/>  <tr>
<td><xsl:value-of select="key('legend',
@financiallegendcode)"/></td>  <xsl:for-each
select="ancestor::financials/perioddata/period"> <xsl:variable
name="idBase" select="@id"/>  <td align="right"> <xsl:choose>
<xsl:when test="$currentFinancial/@periodref=$idBase">
<xsl:value-of select="$currentFinancial[@periodref=$idBase]"/>
 </xsl:when> <xsl:otherwise> <xsl:text>....</xsl:text>
</xsl:otherwise> </xsl:choose> </td> </xsl:for-each> </tr>
</xsl:template>

-- ====================================================================== 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
Keywords