Extending Content Query Web Part with custom data

Have you ever found yourself in a situation when you were working with the Content Query Web Part (CQWP) and you wished it could provide you with some more information? While many SharePoint developers create they custom aggregation solutions you should know better than that. Content Query Web Part can provide you with almost any kind of information that you need and all that with only a few lines of code!

The Content Query Web Part provided with MOSS 2007 is probably the best performing content aggregation solution. Not only it’s best performing but it’s highly customizable as well. Using XSL you can fully control the way the retrieved data is being presented on the page. Personally I find that the MOSS 2007 team did a great job on the CQWP although I know quite a few people who wouldn’t agree with me. Many complain that why the CQWP is indeed highly customizable, it just doesn’t provide enough data to make itself useful in real-life scenarios.

One of many complaints I hear about using the CQWP is the lack of support for multilingual sites. Have you ever tried creating a locale-aware data aggregation using the CQWP where you would not only correct the dates in the correct language but also provide all the labels like “Read more” in the currently selected language? While it seems difficult/impossible to achieve it costs you no more than a few minutes of work to make the Content Query Web Part provide you the locale information and any other data you might need.

Extending the Content Query Web Part

Whenever you need to customize any of the standard functionality of the CQWP you will start off by subclassing it. As Andrew Connell has covered the process and provided some samples I will go straight to the part where you make the CQWP output the information you need.

First of all you need to override the ModifyXsltArgumentList() method:

Now you’re ready to add to the output of the Content Query Web Part your first custom information. Let’s stick to the example I have mentioned and make the locale information available in XSLT so we can format dates according to the current locale.

Using the ArgumentClassWrapper.AddParameter you can include any custom information you want to the XSLT processing of the CQWP. While the CQWP outputs the locale of the current site now, we have to make the XSL files aware that there is an extra property they should use. Make a copy of the /Style Library/XSL Style Sheets/ContentQueryMain.xsl and open it using your favorite text editor. All you have to do is to include the Locale parameter outside the defined templates so it will become globally available.

As you have created a copy of the ContentQueryMain.xsl you have to make your CQWP actually use it. The Microsoft ECM Team has covered the subject of customizing the CQWP extensively so you can follow their guide if you find it difficult to do.

To follow the example, let’s now format some date using the language of the current site. Using the FormatDateTime function of the ddwrt namespace you can format a DateTime value, for example:

<xsl:value-of select="ddwrt:FormatDateTime(@Created, 1033, 'd')"/>

will return the create date of the current page in the en-US notation, like M/d/yyyy (9/2/2008). In the example above the locale is hard-coded in the XSL. If you use the CQWP on a multilingual site you would have to either create another template or extend the one above with some checking mechanism to determine which locale the CQWP should use. As you have extended the CQWP however, you don’t have to worry about that anymore. Just replace the line above with:

<xsl:value-of select="ddwrt:FormatDateTime(@Created, $Locale, 'd')"/>

And the CQWP will take care for the formatting for you automatically!

Summary

Content Query Web Part provides you a very powerful content aggregation mechanism. As it’s highly performing and customizable it suits the most Web Content Management (WCM) solutions perfectly. By extending it with some custom information you can not only make it support multilingual solutions but you can take full control of how the data is being presented in a really efficient way.

Working with the out-of-the-box Content Query Web Part is a little awkward as you have to export and import it in order to access some very useful properties. To simplify working with the CQWP I have created an extended version which not only provides an interface to those hidden properties but supports paging as well. Check out the Extended Content Query Web Part.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WCM, ECM, CQWP