Unlocking the Mysteries of Data View Web Part XSL Tags – Part 2 – <xsl:template>

Cross-posted from EndUserSharePoint.com…

<xsl:template>
Think of a template as a subroutine. It’s a unit of XSL to which you pass control.

A template in a Data View Web Part’s (DVWP’s) XSL is a really important “unit of measure”. When you first drop a DVWP on the page and configure it, SharePoint Designer will automagically create a default set of templates for you. These templates are the scaffolding that holds up the XSL. They are the containers into which you place pretty much everything else (with a few exceptions) and the way that you control the logical flow of the XSL.

If you take the absolutely simplest (and most common) set of actions (drop a DVWP on the page and simply choose to display a list’s Title in a Multiple Item View), you’ll end up with some XSL that looks something like the code example below.

Aside: In this series, I’m going to subject you to my old pal String Bean Man from Office Clip Art. He’s going to point things out to you which I consider best practices, having been writing DVWPs for years. You don’t have to agree with these tips or follow them, but they work well for me. Here’s the first one: The code you end up with won’t look exactly like this because absolutely the first thing that I do when I work in a DVWP is to clean up the code by making the indenting consistent. (I like to use tabs, but in the example below, I’ve used two spaces for each indent, which looks better here at good old EUSP.)

Because SharePoint Designer is fundamentally a code generator, it creates code that contains “stubs” for things that you *may* want to do later. I’ve left everything as is below except for cleaning up the indentations and white space.

<XSL><xsl:stylesheet xmlns:x="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>" xmlns:d="<a href="http://schemas.microsoft.com/sharepoint/dsp">http://schemas.microsoft.com/sharepoint/dsp</a>" version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="<a href="http://schemas.microsoft.com/WebParts/v2/DataView/runtime">http://schemas.microsoft.com/WebParts/v2/DataView/runtime</a>" xmlns:asp="<a href="http://schemas.microsoft.com/ASPNET/20">http://schemas.microsoft.com/ASPNET/20</a>" xmlns:__designer="<a href="http://schemas.microsoft.com/WebParts/v2/DataView/designer">http://schemas.microsoft.com/WebParts/v2/DataView/designer</a>" xmlns:xsl="<a href="http://www.w3.org/1999/XSL/Transform">http://www.w3.org/1999/XSL/Transform</a>" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">

<xsl:output method="html" indent="no"/>
<xsl:decimal-format NaN=""/>
<xsl:param name="dvt_apos">'</xsl:param>
<xsl:variable name="dvt_1_automode">0</xsl:variable>

<xsl:template match="/">
<xsl:call-template name="dvt_1"/>
</xsl:template>

<xsl:template name="dvt_1">
<xsl:variable name="dvt_StyleName">Table</xsl:variable>
<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row"/>
<table border="0" width="100%" cellpadding="2" cellspacing="0">
<tr valign="top">
<xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
<th width="1%" nowrap="nowrap"></th>
</xsl:if>
<th nowrap="nowrap">Title</th>
</tr>
<xsl:call-template name="dvt_1.body">
<xsl:with-param name="Rows" select="$Rows"/>
</xsl:call-template>
</table>
</xsl:template>

<xsl:template name="dvt_1.body">
<xsl:param name="Rows"/>
<xsl:for-each select="$Rows">
<xsl:call-template name="dvt_1.rowview"/>
</xsl:for-each>
</xsl:template>

<xsl:template name="dvt_1.rowview">
<tr>
<xsl:if test="position() mod 2 = 1">
<xsl:attribute name="class">ms-alternating</xsl:attribute>
</xsl:if>
<xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
<td width="1%" nowrap="nowrap">
<span ddwrt:amkeyfield="ID" ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" ddwrt:ammode="view"></span>
</td>
</xsl:if>
<td>
<xsl:value-of select="@Title"/>
</td>
</tr>
</xsl:template>
</xsl:stylesheet></XSL>

If you look through this example, you’ll see that there are four templates:

<xsl:template match="/">
<xsl:template name="dvt_1">
<xsl:template name="dvt_1.body">
<xsl:template name="dvt_1.rowview">

There’s nothing magic about the fact that there are four or what their names are. SharePoint Designer just creates templates with these names every time. Each of these templates has a specific purpose, as things are currently set up:

<xsl:template match="/">

Matches the “root” of the nodeset tree. The way I think about this is that it is the “initiating function”.

<xsl:template name="dvt_1">

This template is where the nodeset (set of rows) is retrieved from the DataSource and the rendered output is started (in this case).

<xsl:template name="dvt_1.body">

This template is where things which should happen at the nodeset level will occur. For instance, if you decide to sort the rows, it will happen here.

<xsl:template name="dvt_1.rowview">

This is the “meat” of the DVWP, where we work with each row, outputting the values.

Another thing that I do early in my editing is to rename the templates to better reflect what I’m doing. In this case, I’m working with my standard Sales Opportunities demo list, so I’d rename the templates like this:

<xsl:template match="/">
<xsl:template name="Sales_Opportunities">
<xsl:template name="Sales_Opportunities.body">
<xsl:template name=”Sales_Opportunities.rowview">

There’s no requirement to do this, but it can make things easier down the road, especially if you decide to use additional lists in the DVWP (an AggregateDataSource). “dvt_1” just doesn’t feel that descriptive to me.

In this example (which I will continue to use in this series), each template passes control to the next (using <xsl:call-template>, but that’s the next article), as appropriate. I’ll go into the specifics of how that works and what happens in each of the templates later in the series, but this is a high level view of what they are there for and what they each do.