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

Re: [xsl] Can this hard-coded template be generalized?


Subject: Re: [xsl] Can this hard-coded template be generalized?
From: "Mark" <mark@xxxxxxxxxxxx>
Date: Sun, 2 Oct 2011 16:40:38 -0700

Thanks,
That will take a bit of digesting - I have to learn more XPath! I did not even know there was a distinct-values().
Enjoy the rest of your Sunday,
Mark


-----Original Message----- From: G. Ken Holman
Sent: Sunday, October 02, 2011 4:26 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Can this hard-coded template be generalized?


At 2011-10-02 15:40 -0700, Mark wrote:
I'll be looking for your book/DVD announcement.

The DVD was announced three years ago and there are no changes there:


http://www.CraneSoftwrights.com/training/ptux/ptux-video.htm

... what is new is the open book availability and purchase covenant.

Earlier, you mentioned the unnecessary grouping in my code. Since this is a pattern I often use, I'd like to know if there is a simpler way. Here is the reason I did the grouping :

This time, the goal is to write both buttons (complex=105 and complex=107) as before, but now to the same document.

*That* tells me to use grouping because of the uniqueness.


Also, they need to be numbered sequentially starting with '1'. (The Czech language button simply reflects localization).

You're safe in what I see because position() reflects the position of the group.

[By the way, the file names change rapidly from format to format. While they won't be needed later, right now the string disassembly prevents my making even more typos.]

[a processor may even internally rewrite the single use of a variable into inline code and thus not incur the overhead of storing the variable]

<xsl:if test="cps:page-type($file-type) eq 'souvenir-sheet'">
<xsl:for-each-group select="../Stamp/Formats" group-by="@complex">
<xsl:variable name="file-name" select="concat(substring-after($page-name-stem,'aip/'), @complex, 's.htm')"/>
<a lang="en" class="button" href="{$file-name}">
<xsl:text>Se-tenant </xsl:text>
<xsl:value-of select="position()"/>
</a>
<a lang="cz" class="button" href="{$file-name}">
<xsl:value-of select="position()"/>
<xsl:text>. Spojky</xsl:text>
</a>
</xsl:for-each-group>
</xsl:if>

Looks fine to me! (though I don't see where you are using xsl:result-document)


Last time you wanted one file per Stamp and so the grouping was
inappropriate.  Here you are dealing with the uniqueness of @complex
and so grouping is perfect.  You would also use grouping when wanting
to collect all of the items that share a common value ... in which
case the current-group() gives you the members of the group.

I see one simplification, since (a) you aren't collecting the
like-valued members, and (b) you aren't dealing with any piece of
information other than the complex attribute, is to just use
distinct-values().  I haven't tested this, but something along the lines of:

     <xsl:for-each select="distinct-values(Stamp/Formats/@complex)">
       <xsl:variable name="file-name"
select="concat(substring-after($page-name-stem,'aip/'), ., 's.htm')"/>
       <a lang="en" class="button" href="{$file-name}">
         <xsl:text>Se-tenant </xsl:text>
         <xsl:value-of select="position()"/>
       </a>
       <a lang="cz" class="button" href="{$file-name}">
         <xsl:value-of select="position()"/>
         <xsl:text>. Spojky</xsl:text>
       </a>
     </xsl:for-each>

In the above the context node "." in the loop is the string of the
attribute (not the attribute itself) and so you leverage it to find
surrounding source tree information.  If you still need access to the
source tree, use the grouping method to preserve the nodes.  Note
there is no definition of "/" (root node) when "." isn't a node.

I hope this helps.

. . . . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


Current Thread
Keywords
xml