Did You Know: Include XSL In SharePoint Search Results


Maybe some of you already knew this, but I sure didn't until I tried it. Thanks to Ian Morrish for his post about the XSLT Standard Library for helping me put the pieces together.

So my little journey into customizing SharePoint Search Results started a few days ago. I won't go into a ton of detail because there are plenty of good blogs out there on how to do this, and anything I have to say on the subject will likely go into our internal knowledge base. It suffices to say that the method of using XSL to transform the rendering of search results is about a thousand times better than the crazy web part development that I had to do in 2003 in order to accomplish the same results.

But my headaches began when I decided to try and make use of XSLT 2.0 function capability to leverage some nifty string manipulations like those found here. I needed to use something like "substring-before-last" to trim the file extension off the end of document titles (really, URLs) that were coming from a search protocol handler for content outside of SharePoint.

Try as I might, I could not get it to work, and the error information for XSL validation is hidden from you, so my attempts to determine the cause were only causing me more grief. I could switch the stylesheet to version 2.0, add the necessary namespaces, and even declare functions with xsl:function. But whenever I would try to call the function (even with constants) I would get that monolithic web part error "Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator."

So, in the end here is what I was able to do. I downloaded the entirety of the XSLTSL zip file and uploaded its contents into a document library on my SharePoint site using Explorer View. (I safely ignored the error I got from one file that wouldn't upload.) This makes all the XSL files web accessible, but I suppose there could be other approaches that would work just as well, like uploading these files into a subfolder under "/_layouts/".

Now, I tried making the xsl:import tag work, but there was no love there. However, xsl:include seems to work just fine. I wonder why the SharePoint folks don't make more use of includes in their own XSL. Though I guess it wasn't strictly necessary, it would've made for cleaner code and easier customization of things like Data Form Web Parts and such.

So, once you have you library chock full of stylesheets, modify the top level tag of your Search Results XSL to look like this:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:doc="http://xsltsl.org/xsl/documentation/1.0" xmlns:str="http://xsltsl.org/string" extension-element-prefixes="doc str">
Then, add includes just below the last "xsl:param" tag, like so:

<!-- Import libraries for common use -->
<xsl:include href="/XSL%20Library/xsltsl-1.2.1/string.xsl" />
You can add as many includes as you like. Generally I try to only include the ones I will actually be using. The URL for the include statement should point to the path of the desired XSL document on your site. I was able to get both absolute URLs (with protocol and DNS names) and root relative URLs (leading slash) to work, but I didn't try file system based URLs to see if they would work.

Now, you can use the templates defined in the included file just like they were declared directly in the web part itself.

In my example, I put this tag between the document title and the description.

<!-- code added - TC -->
<div style="font-weight:bold; color: red">
<xsl:call-template name="str:to-upper">
<xsl:with-param name="text" select="title" />
<!-- end code added - TC -->
<div class="srch-Description">

The results look like this:

Custom Search Results Screen Capture

If I were to dig through all these function, I bet I could think up some fancy stuff to try. Better yet, why not make an XSL template library specific to SharePoint and share it with the community?


What tool should you use to Deploy SharePoint Projects?

At this point, I have tried them all. I hand rolled my solutions; used early versions of WSPBuilder; struggled with the interface for VSeWSS 1.0, 1.1 CTP, and 1.1 final; and even tried a few offbeat solutions.

Until this summer, every method had serious problems that made packaging and deployment problematic. Revisiting my posts, I see that I never mentioned this before, but I owe props to my colleague Ted Calhoon who turned my on to the WSPBuilder Extensions. I switched over, and I never looked back.


They are a bit counterintuitive, and the commands to flush out the folder structure are well buried, but once you get the hang of them, they are the best around - at least until someone comes up with something better.

In future, I'll do a walkthrough.

Update 5/1/2010: Microsoft has finally delivered a tool of their own with Visual Studio 2010. We've played with it a few times, and may still need to use WSPBuilder extensions for some time to support our legacy projects. They're very similar, and it appears that the SharePoint tema got this part right for the new version.