Unlocking the Mysteries of Data View Web Part XSL Tags – Part 4 – <xsl:with-param>

This entry is part 4 of 21 in the series Unlocking the Mysteries of Data View Web Part XSL Tags

Cross-posted from EndUserSharePoint.com

<xsl:with-param>

You use this with <xsl:call-template> when you want to pass a value into a template, usually a value that varies.

Once you’ve laid down the foundation and framed the rooms with <xsl:template> and <xsl:call-template> (one of my goals in this series is to mix as many metaphors as possible), you can start building out. <xsl:with-param> is the way you can send variable information into a template for it to work with. Templates need some fodder to work with (see: another metaphor!) and <xsl:with-param> is a way to provide it.

<xsl:with-param> can only be used with <xsl:call-template>, so it passes the value into the template which you are calling just like you would do with a function or procedure in many other programming languages. If we look at the standard example again, you can see that some <xsl:call-template>s pass in parameters and some do not:

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

So you can see that the call to dvt_1.body passes the Rows parameter:

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

and the call to the dvt_1 template passes no parameters:

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

(There’s also a sort of “implied” parameter pass with <xsl:for-each>, but that will have to wait for the <xsl:for-each> installment.)

If you set some of the options on a DVWP, you may see a longer list of parameters passed into a template. For instance, if you turn on paging, you’ll see this in the call to dvt_body:

<xsl:call-template name="dvt_1.body">
  <xsl:with-param name="Rows" select="$Rows"/>
  <xsl:with-param name="FirstRow" select="1" />
  <xsl:with-param name="LastRow" select="$LastRow - $FirstRow + 1" />
</xsl:call-template>

These extra values are required to make the paging work.  FirstRow is always set to 1, which isn’t very interesting, but LastRow is calculated to be the value of $LastRow - $FirstRow + 1.  Variables or parameters are referred to with a preceding dollar sign, and list columns with a preceding @ sign.  So $FirstRow would be a parameter or variable called FirstRow, where @FirstRow would be the value of a list column called FirstRow.

Frankly, if you try to trace through some of what SharePoint Designer creates along these lines, it may seem like total gobbledy-gook. This is primarily due to the fact that Designer needs to be “prepared” for the other options you might choose, and also due to the fact that it needs to add in XSL for boundary conditions that you may not think of. (First rows, last rows, etc.)

Next up: <xsl:param>. A value you’ve passed into a template with <xsl:with-param>. You need to have an <xsl:param> at the top of the template for each value you expect to be passed into it.

Series Navigation<< Unlocking the Mysteries of Data View Web Part XSL Tags – Part 3 – <xsl:call-template>Unlocking the Mysteries of Data View Web Part XSL Tags – Part 5 – <xsl:param> >>

Similar Posts

9 Comments

  1. Do you know how we can set which record the dataview starts displaying when set to display a set number of records with paging between records? I thought it had something to do with FirstRow or dvt_firstrow but changing these values either has no effect or causes the dataview to display incorrectly.

    1. Ryan:

      If you change the page you are looking at, you’ll see that SharePoint does a postback with a value on the Query String. That’s the default mechanism. Of course, you can make it work anyway you want by building a DVWP and/or layering in some script.

      M.

  2. Hi I was wondering if there is a way to change the value of dvt_firstrow from code behind. I’m trying to replace the standard pagination of the DFWP. I was wondering if you could help me with this. Thank you. :)

    1. Adrian:

      Can you explain more about what you are trying to do? If you simply want to change the number of items per page, there’s a setting for this in the Common Dialogs.

      M.

      1. I encountered an issue with the previous button of the pagination in DFWP. Whenever I clicked on it the page would generate a “webpage has expired” error. So I tried to change the previous button functionality by replacing history.back() with a script that runs a code from code behind. I am now able to display the correct data on the DFWP but my problem is that the first row to last row and the dvt_nextpage values on the DFWP remain unchanged. I was wondering if there was a way to be able to manipulate the dvt_firstrow variable on the DFWP. Hope you understand me. I’m not so good at explaining stuff. Hope to hear from you soon. Thank you. :)

        1. Adrian:

          From the sounds of it, you’re trying to put a bandage on a bandaid. I’d suggest starting a new DVWP to see if you have the same issue. If you do, then there’s something wrong with your setup somewhere that has nothing to do with the DVWP. If it doesn’t recur, then just build up the DVWP again.

          M.

          1. Yup. I’ve tried making a new DFWP but still the same results. We have another DFWP on another page and it works fine there. We just encountered this issue on this specific page. I’ve also tried taking the DFWP out of my user control but it’s still the same. Could there be a way for me to build a dvt_nextpagedata like parameter? Sorry I’ve been stuck on this problem for the past three weeks and it’s really been frustrating.

            1. Ok, then I’d say the next step is to figure out what is different about that particular page. You might want to start with a copy of the working page and go from there. Or, you can copy the DVWP code from the working page into the broken one and see if that works.

              There will be a solution if you empirically test the variations.

              M.

Leave a Reply to Adrian Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.