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

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(_at_)syr(_dot_)edu>
> 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(_at_)mulberrytech(_dot_)com>  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(_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>
--~--