If you have used the out of the box SharePoint Data View (aka Data Form) Web Part, you probably have seen the functions with the “ddwrt” prefix. These functions are called XSLT Extensions and they are functions that are written in managed code. In this post I will described how you can write your own XSLT Extension functions, which makes the very powerful Data View web part even more powerful. In a next post I will describe in which scenario I have used this technique. In this post we will do a simple Hello World.
Step 1 – Create the extension object
The first thing to do is create a new extension object. Very easy to do. The code is shown in the snippet below:
namespace EOF.ExtensionDataFormWebPart
{
public class EOFXsltExtension
{
public string HelloWord()
{
return "Hello World!";
}
}
}
Step 2 – Create the web part
In this step we create a new Data Form Web Part, that inherits from the out of the box Data Form Web Part. The Data View Web Part is the same as the Data Form web part. In this web part, we override the function ‘ModifyXsltArgumentList’ and in the new implementation, we add our new extension object. By doing this we tell the web part where to load the custom functions that we are using in the XSLT:
namespace EOF.ExtensionDataFormWebPart
{
public class ExtensionDataFormWebPart: DataFormWebPart
{
protected override void ModifyXsltArgumentList(ArgumentClassWrapper argList)
{
base.ModifyXsltArgumentList(argList);
if (argList == null)
{
return;
}
argList.AddExtensionObject("urn:EOF-XsltExtensions", new EOFXsltExtension());
}
}
}
Step 3 – Build and install the web part
I will not describe how to build and deploy this web part, there’s a lot documentation on this. After you installed the web part, you should be able to drag it onto a page. Your page will then look like this:
Step 4 – Test the HelloWorld function
The last step is to test our new XSLT Extension. That part is a bit tricky, because SharePoint Designer does not behave very well when configuring our custom Data View web part. To configure our web part, I first configure an out of the box Data View web part. I write all the XSLT up to a point where I need my custom functions. Then I add my ExtensionDataFormWebPart to the page, and copy the configuration in SharePoint Designer’s code view to the new web part. At this time, your page will have 2 identical web parts:
The first thing to do next is to register the namespace for our custom XSLT Extensions (I added the last line):
<xsl:stylesheet
xmlns:x="http://www.w3.org/2001/XMLSchema"
xmlns:d="http://schemas.microsoft.com/sharepoint/dsp"
version="1.0"
exclude-result-prefixes="xsl msxsl ddwrt"
xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
xmlns:asp="http://schemas.microsoft.com/ASPNET/20"
xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
xmlns:SharePoint="Microsoft.SharePoint.WebControls"
xmlns:ddwrt2="urn:frontpage:internal"
xmlns:eof="urn:EOF-XsltExtensions">
Then we can use our HelloWorld function in the XSLT code:
<td class="ms-vb">
<xsl:value-of select="@Editor" disable-output-escaping="yes"/>
(<xsl:value-of select="eof:HelloWord()"/>)
</td>
If you now save the page, your web part will look like this in SharePoint Designer:
I will try try to work out why this is, and how I can get it to work normally. If you have any suggestions, please let me know.
Although SharePoint Designer displays our web part a bit funky, if we reload the page, it looks like this:
We now have the output of our managed code XSLT Extension function in the output of the web part. That is nice, isn’t it? I will try to work out the strange side effects when working with this web part in SharePoint Designer. In the next post I will describe how I have used this.