In a previous blog post I talked about how you can use XSLT to display additional Managed properties returned from Search. In this post I want to talk about the method I went about to create the XSLT in the hopes that you find it an interesting enough pattern to use should you find yourself creating some of the same visualizations for Search, the CQWP, Lists, or the BCS WebParts which all use XSL to transform XML into HTML.
The process of writing XSL transforms is a bit like an algebra equation where you are solving for the unknown. For example, you are moving through a pipeline of sorts XML –> XSLT –> HTML where the unknown is the XSLT which you need to develop. As in algebra this is a heck of allot easier when you are solving for just one unknown, so this means to get started you need to nail down the other two variables, the XML and the HTML.
The HTML can be mocked up to represent the finished product and then shopped around to get by in from your stakeholders to ensure you are producing the results they require before getting started. Once that is set you need to get your hands on the XML which will be the source data you will begin to refactor into your mockup HTML. The source of the XML in this example will be from Search as a response from a query. The easiest way I have found to get a sample of XML from Search is to edit the properties of the Core Results WebPart and replace the default XSLT with the XSL below. This XSL just simply passes through the XML directly onto the page which is hosting the webpart (in our case the Core Results WebPart).
<?xml version="1.0" encoding="utf-8"?> <!-- THIS XSLT Gets the XML document passed in and returns it--> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"> <xsl:output method="xml" indent="yes"/> <xsl:template match="@* | node()"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet>
Saving this configuration and supplying a sample search will result in an ugly looking page. Open that page’s source by doing a “view source” and search for “All_Results”. This is the beginning tag of the XML we are after, copy that XML all the way to the ending </All_Results> and paste that into a new XML file named something like results.xml (leave the XML prelude if using VS to create the XML file).
So at this point you have the XML and a mockup of what you want your HTML to look like – so lets solve for the unknown, the XSLT. Now if you thought I was going to teach you XSL via a blog post I am sorry to disappoint but that topic will not scale to what I can do on this blog. There are tons of sources on the Internet and books which will do a much better job that I can ever do so I will redirect you to those at this point.
As for tools for creating XSLT I use Visual Studio 2010. I start by creating an empty project and importing my XML file into the project and then either create a new XSLT file or start from an existing file as I did in my previous post. What is really cool about using Visual Studio 2010 is that you get all the color coded XML and XSLT plus Itellisence. And if that were not enough you can also debug your XSLT using the XSLT Debugger (this was in VS 2008 too).
With your XSLT selected choose the XML menu item and “Start XSLT Debugging”. The first time you will be asked to supply a source XML file. VS 2010 will allow you to set breakpoints, execute, and step through the XSLT just as you can do with many of the other development languages VS supports. For example, take a look at the following screen shot, I am about to call into a template named FormatRating where I have set a breakpoint and VS has broken into. (click on the picture to make larger). As you can see I have setup 3 windows much like the pipeline concept I mentioned earlier: XML –> XSLT –> HTML. Notice how I can see the point within the XML along with the next line to be executed within the XSLT along with the current HTML buffer which has been flushed.
Using F5, F11, F10, and Shift-F11 I can execute, step into, step over, or step out of XSLT calls. In this case hitting F11 drops me into the FormatRating template where I can step over several variable initialization lines. From this next screenshot you can see how I added a few watch variables, the first two of which were parameters which were passed into my template and the last few are template local variables which I have manipulated some data into a desired format.
So just to wrap this up using Visual Studio 2010 with a source XML file and a solid idea of what you want to produce is a great way to create custom visualizations for many different SharePoint components which leverage XSLT.