This post will highlight a number of topics specific to XSLT customization with SharePoint. Some topics may be further explored in future blog posts.
What is XSLT?
XSLT is a declarative language for performing XML document conversions. XSLT allows you to format structured data (XML) with powerful stylesheets (XSL), to generate a brand-new XML document.
In short, it allows you to separate data from presentation. Common uses for XSLT include website content creation, end-user configuration, and document conversion.
XSLT is interpreted, not compiled. This means that you can change XSLT files in custom solutions without having to recompile and re-deploy assemblies.
Why XSLT?
SharePoint relies on XSLT to generate the majority of its dynamic content. Everything from lists to search results to RSS feeds is internally powered by XSL transformations. Some of these are obvious (the Content Query Web Part and Data View Web Part). But some are subtle (Search Results web parts, Business Data Catalog web parts).
You may be surprised to learn that XSLT is used extensively throughout SharePoint. From There are many situations where XSLT is the best option:
- Skinning XML without "reinventing the wheel"
- Making small changes without compiling code
- Exposing configuration options to end users without letting them touch application code
There are also situations where XSLT is the only option:
- Smaller deployments of SharePoint Online (BPOS) don’t support custom assemblies, but they do support XSLT
- Users with limited SharePoint access may be prohibited from deploying custom executables, but still be permitted to tweak XSLT
- Some vendors provide XML data over web services which need to be presented in the browser through Javascript (AJAX), making XSLT the only viable choice
SharePoint’s XSLT implementation
WSS and MOSS 3.0 are both built atop the .NET 2.0 framework, which implements XSLT 1.0 within the System.Xml.Xsl library. This is important to note because SharePoint 2007’s XSLT functionality is only as powerful as .NET 2.0’s.
As of March 2009, Microsoft has not announced support for XSLT 2.0, so it is not expected within .NET 4.0. That said, the next version of SharePoint (14) will almost definitely be limited to XSLT 1.0.
Also note that some tools use XSLT on the client-side using Javascript. Internet Explorer performs those transformations using a separate library (MSXML). The MSXML 4.0 library is also limited to XSLT 1.0 and Microsoft has announced that future versions will also be limited to 1.0.
Where XSLT is used
As previously mentioned, XSLT is used extensively throughout the SharePoint ecosystem. The majority of out-of-box web parts rely on it, including list and document library views.
Each site collection in SharePoint has a special document library called "XSL Style Sheets" (within the "Style Library"). The easiest way to explore these documents is using SharePoint Designer. This library contains a handful of pre-built XSL stylesheets that drive the system’s look and feel:
- Header.xsl: column header and grouping styles
- ItemStyle.xsl: main stylesheet for controlling DIV- and TR (row)-level styling
- ContentQueryMain.xsl: overall structure of Content Query Web Parts
- LevelStyle.xsl: uses in various places
- RSS.xsl: default look of RSS Feed Web Parts
- SummaryLinkMain.xsl: structure for Summary Link Web Parts
- TableOfContents.xsl: used in the Table of Contents Web Part
Many web parts default to relying exclusively on these stylesheets. However, all styles can be overridden. There are three basic ways to customize a web part’s XSLT:
- Edit the pre-built XSL file within "XSL Style Sheets"
This is the quickest and dirtiest option, but also the one I’d least recommend since it customizes (unghosts) SharePoint’s stylesheets.
Be aware that many websites suggest this route. It’s easy, but not scalable.
- Edit the web part’s XSL directly within its properties
By exporting a web part to its serialized .DWP or .WEBPART file, you can manually edit all of its properties. You might be surprised how many settings are available when working directly with a .WEBPART file.
This approach has the major advantage of being self-contained. If you style a web part without referencing external files, you are guaranteed that it will work the same way on other machines.
- Build and reference a custom XSL file
Perhaps the best option, building your own XSL stylesheet puts you in total control and allows for easy migration. You can build an XSL file in Visual Studio as part of your feature or solution and thus keep styling within source control.
Keep in mind that you don’t need to start from scratch; copying existing templates (such as ItemStyle.xsl) is a great way to start.
This is a complex topic, but there are a few great blog posts that can help you get started:
- Microsoft ECM Team Blog: Configuring and Customizing the CQWP
- Heather Solomon: Customizing the CQWP and Custom Item Styles
- Brendon Schwartz: Connecting the CQWP without changing ItemStyle.xsl
SharePoint-Specific XSLT Libraries
The XSLT spec allows for third-party functionality to be added through extension objects . Microsoft anticipated some SharePoint-specific template requirements and included two powerful custom libraries (I’m not sure what either acronym stands for.):
- DDWRT Namespace
Provides dozens of useful end-user functions such as IsPrivilegedUser() (for determining if working with an administrator), UserLookup() (for mapping usernames with data such as email addresses).
I touched on the DDWRT namespace and URLEncode function in a previous blog post.
- CMSWRT NameSpace
This little-documented extension provides a number of internal utilities. Rarely will you directly interact with the CMSWRT namespace, but it does include some useful functions such as RegisterFeedURL and EnsureIsAllowedProtocol.
Other uses for XSLT with SharePoint
There are countless ways to utilize XSLT in SharePoint besides tweaking web parts. You can render vendor data on the client through AJAX. You can also create cool, extensible slideshows with Silverlight. You can even convert between Word documents and InfoPath forms programmatically. The options are limitless.
Resources for learning XSLT
The best book I’ve found for truly understanding the subject is XLST 2.0 and XPath 2.0 Programmer’s Reference by Michael Kay (editor of the W3C XSLT 2.0 spec).
There are also some good online tutorials:
