Structured and repeatable deployment of Content Query Web Part instances

Content Query Web Part (CQWP) is probably the best solution for data aggregation within SharePoint 2007 solutions. The limited functionality exposed through the standard UI is compensated by caching and high performance of the CQWP. Yet there is one thing that can keep you off using the CQWP in environments which require you to deploy your solutions including the configuration in a fully structured and repeatable manner.

The Content Query Web Part produces the query results as XML and uses XSL for creating the presentation layer. This approach introduces great flexibility and reusability of one and the same web part in almost every scenario possible. One of the many usage scenarios of the CQWP are the Web Content Management (WCM) projects - Internet-facing sites which have to be high performing. In all these projects you are very likely to have to modify the XSL Style Sheets used for creating the presentation layer of the Content Query Web Part to meet the UI of the web site you’re creating. There are two approaches to achieve that.

Modifying the existing XSL Stylesheet

Although it’s not the best idea to modify any of the files shipped with SharePoint, I have picked this approach to illustrate you the whole issue. You will understand why, after I presented you the other, slightly more complicated, approach.

According to the SharePoint architecture, one Feature is not allowed to modify any of the files deployed by another Feature. As we’re talking about a structured and repeatable deployment, using Feature is probably something you are using in your solution to provision the files. The architecture limitation I have just mentioned, creates a big challenge: how to deliver the customizations you have done in your development environment? Because you are not allowed to modify the existing ItemStyle.xsl, you will have to deploy your own xsl file containing your presentation layer. Another challenge arises…

Providing a custom XSL Stylesheet

Using a custom XSL Stylesheet (let’s call it Custom.xsl) seems to be the most logical way to deliver customization to the customers. Deploying a custom file in a structured and repeatable way is really straightforward and can be done using Features.

After having deployed the Custom.xsl it’s time to make all the instances of the Content Query Web Part to use it. By now you have probably created something what resembles Imtech SharePoint OCD: a tool which helps you deploying SharePoint configuration stored in an XML file, Excel or anything else. This is when it all goes wrong.

While setting any of the three XSL stylesheets (MainStyle, HeaderStyle or ItemStyle) the CmsDataFormWebPart, from which the Content Query Web Part inherits, tries to turn the given URL’s into server relative ones. It uses the information stored in SPContext to determine the URL part of the current Site Collection. As almost every configuration provisioning tool is either a console or a Windows application, it doesn’t have the SPContext information. Trying to provision an instance of the CQWP using a custom XSL stylesheet will result in the “Value cannot be null” exception thrown by the SPLimitedWebPartManager.

I have to admit, I have spent a lot of time thinking of how to solve this challenge and benefit of the Content Query Web Parts while deploying the configuration in a structured and repeatable way. Just recently I have found a solution.

You want some context?

The solution is pretty simple. Yet it’s definitely something you have to know about. All you need to do, in order to deploy a new instance of the Content Query Web Part using a custom XSL stylesheet is to provide the HttpContext information:

if (HttpContext.Current == null)
{
  HttpRequest request = new HttpRequest("", web.Url, "");
  HttpContext.Current = new HttpContext(request,
    new HttpResponse(new StringWriter()));
  HttpContext.Current.Items["HttpHandlerSPWeb"] = web;
}

Where web is an instance of SPWeb (in many cases you will set it to the equivalent of SPContext.Current.Site.RootWeb).

To make it all work you need to provide the information presented above either just before calling the SPLimitedWebPartManager.AddWebPart method or calling it at the beginning of your script and reuse it for any object which requires the SPContext information.

Summary

The Content Query Web Part is the best data aggregation solution available in SharePoint 2007. Its flexibility and extensibility make it a great solution for presenting aggregated data on Web Content Management solutions. In spite of its great power, the Content Query Web Part cannot be instantiated outside the SharePoint Web UI, because it requires the SPContext information to save the links to custom XSL Stylesheets. By providing the context information using custom code, you can leverage the concept of flexible and great performing data aggregation solution and deploy your instances of the CQWP in a structured and repeatable way.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007

Others found also helpful: