Custom Controls in XSLT

Background & The Dream

SharePoint relies heavily on XML data and XSLT processing of such data. Whether we are dealing with Search results, Data view web parts or Content Query web parts, XSLT processing is something all SharePoint developers have to deal with on regular basis. SharePoint provides an XSLT extension object called ddwrt to perform tasks such as accessing properties of a SharePoint list or firing events to connected Web Parts.

Even though XSL transforms are incredibly powerful, especially with the availability of extension objects like ddwrt, sometimes it is much quicker and easier to perform advanced processing using server side controls. In other cases, it’s almost a necessity. Imagine being able to take xml data and query external web services during the transformation process to render customized contextual information about the data being displayed to the user.

For example, let’s say we were to implement a staff directory using SharePoint people search. The underlying data is stored in the User Profile service application and the results are rendered using the people core results web part. However what if instead of simply displaying a list of people, we additionally wanted to display a list of projects that they are participating in? In this case, imagine the power of being able to insert a server side control in the XSLT to query a 3rd party project management system to retrieve the list of a particular user’s projects and then rendering that nested within the rest of the XSL transform

How to do it

There are 4 steps needed in order to be able to insert server side controls within a SharePoint XSLT-

1. First thing we need to do is to write the control that we will be inserting into our XSLT. Notice that we are declaring two public properties called ‘itemUrl’ and ‘print’. These properties are used to pass xml data at run-time into our control. We are also overriding the Render method which is used to spit out the code that will be output to the end user-

namespace PortalSolutions.WebUI.Controls
{
    public class SampleFields : Control
    {
        public string itemUrl;
        public string print;

        protected override void Render(HtmlTextWriter writer)
        {
            writer.Write("<div>Hello World</div>");
        }
    }
}

2. The next thing for us to accomplish is to globally register our assembly and a tagPrefix for this assembly so that SharePoint can find our control. This is done because we don’t have access to register our assembly from within the XSL editor on SharePoint web parts. This registration is added in the web.config under the following node:  <configuration>…<system.web>…<pages>…<controls>-
   

   <add tagPrefix="PS" namespace="PortalSolutions.WebUI.Controls" assembly="PortalSolutions.WebUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=00aaa666444222cc" />

3. Now that SharePoint knows about our assembly and can find the control, we have add a declaration on top of XSL to attach a prefix to our namespace so that we can reference our control. In this case, ‘PS’ is the tag prefix we will be using-
   

   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:PS="PortalSolutions.WebUI.Controls" >

4. Finally, now that we have everything set, we simply have to reference our control where we want to render it by using our tag prefix we registered in step 3 and the name of our control class which in this case is ‘SampleFields’. Additionally we use the public properties declared in the control definition as attributes in our XSL to pass in any information that the control may need to process the current XML node-
   

   <PS:SampleFields itemUrl="{$url}" print="HelloWorld" runat="server" />

And there we have it! A custom server side control puts a lot of power in the hands of developers looking to deliver some really powerful and amazing solutions.