Unlocking the Mysteries of Data View Web Part XSL Tags – Part 1: Overview

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

Cross-posted from EndUserSharePoint.com

Data View Web Parts (DVWPs) are, to me, the most powerful feature in SharePoint. You’ve probably heard them called the Swiss Army Knife of SharePoint and there’s really very little that you can’t display with them if you understand how they work. But understanding the inner working of DVWPs requires knowledge of some pretty crufty concepts: CAML and XSL. In this series, I hope to demystify the XSL side of things a bit by explaining the most common XSL tags you’re likely to see in DVWPs and what you can do with them.

For this first post in the series, let me list out what I see as the most common XSL tags used in DVWPs generated only by using SharePoint Designer’s dialogs. You’re liable to see most, if not all, of these tags if you switch to Split or Code view and start rummaging around in the code. The definitions are mine, and I intend them to be simplistic, so you purists out there may need to check your vocabulary at the door!

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

This is how you call a template which you’ve defined with <xsl-template>.

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

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.

A value you create for use within a template which is only defined within the scope of that template.

A way to iterate over a nodeset (group of rows).

Used within an <xsl:for-each> to determine the sort order in which the nodeset (group of rows) are processed.

A single conditional test. If the test is true, then the contained code is executed.

Like <xsl:if>, but with multiple possibilities, more like if-then-else.

Used within <xsl:choose> as a conditional test. If the test is true, then the contained code is executed and the <xsl:choose> is exited.

Used within <xsl:choose> as the “fall-back” condition. If none of the prior <xsl:when>s have been executed, the code contained here is executed.

Outputs the value to which it evaluates, whether it be the value of a column, a variable, etc.

There are more XSL tags available, but this set is what you are most likely to run into in a Data View Web Part (DVWP). As we continue on with this series, I’ll give some examples of how you may see each of these tags used, some other interesting things you might want to do, and the results.

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


    • Steve:

      Thanks for the link. That looks like a useful article as well. One of my goals for this series (which I’m publishing over at EndUserSharePoint.com first) is to explain the XSL in the context of a SharePoint DVWP. In general, the answers are the same, but it’s a different context, so there may be some nuances. I’m also consciously going to try to avoid the jargon which makes XSL seem so unfathomable to many people (it certainly was to me until I “got it”!).


    • I think that SharePoint Designer is the best tool, as it “understands” DVWPs better than anything else you might use. That said, the XSL aspect of a DVWP is fairly standard, from what I’ve been able to determine. What specifically would want you to switch to something other than SPD?


  1. Hi, Marc,

    I’ve been trying to figure out something for ages. I want to put a DVWP in a page template so that it displays content depending on metadata values in the published page. For example, I want to be able to add some metadata values to a page (I used a content type to make the end user’s job easier). Then, when a page is finished, I need the page to look at the metadata, then display icon images (using a few xsl:when queries) for each particular page.

    What’s giving me the problem is that the DVWP is acting on the metadata from the oldest page in the Pages directory. I need it to pull metadata for the current page … is this making any sense?

    I wondered if there was a CAML variable solution, but I’ve been Googling for hours and I can’t find anything approximating a solution.


    • Alan:

      If you’re putting the DVWP in the page layout, then you can certainly read a value from another control in the page using a parameter. It sounds like you are running into some sort of disconnect when it gets to the actual pages generated from that page layout, however. I can’t recall a time where I’ve done exactly what you describe, but I can’t think of a reason why it wouldn’t work. You probably will have to use the URL so that the DVWP “knows” which page it is on, or the page’s ID in the Pages library.


      • Hi, Marc,

        Thanks for the response. I have now managed to figure out what the problem was. It is the peculiar and different behaviour of the Parameters in SharePoint.

        I’d started off using the PageUrl Parameter, but oddly, that returns values in SP Designer but not in the browser. This drove me nuts for a couple of days, because I couldn’t figure out what I was doing wrong. Then I chanced on another post that mentioned the ServerVariable option. So I tried ServerVariable(URL). Maddingly, this didn’t work in SP Designer’s design view, but – blow me down, Olive – it worked in the browser window.

        So I was able to call back metadata (pulled from a Content Type related to the page I was on) and use it to display icons peculiar to that current page …

        As this is such a badly documented “feature” of SharePoint, I think I’ll write up a full explanation on my own blog ASAP …

        But thanks for your help, Marc!


Have a thought or opinion?