Extending Content Query Web Part with custom data
Content Query Web Part, SharePoint, Tips & Tricks, WCMHave 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.
December 28th, 2008 at 6:09 pm
Thanks for the ECQWP Waldek.
I am really struggling to understand the 3 XSL files that are shipped ContentQueryMain.xsl, ItemStyle.xsl and Header.xsl. I tried to read the article here: http://msdn.microsoft.com/en-us/library/bb447557.aspx but still not able to understand why we need 3 different XSL files. If we are implementing a completely custom style can't we just use the ItemStyle.xsl file. Can you explain (in simple layman terms) about why we need these 3 XSL files.
thanks
MB
December 28th, 2008 at 8:37 pm
If creating a custom display style is all you want to do, modifying ItemStyle.xsl is enough. ContentQueryMain and Header can be used to modify for example how the cqwp renders groups, columns, etc. It is ok to provide a custom ItemStyle.xsl and use the other two standard cqwp files
March 7th, 2009 at 4:03 am
Hi Waldek,
I wanted to know how to hide the ECQWP if the web part doesnt render any records. Basically the requirement is to hide the webpart if there are no records to render, how can we do this? Javascript? But then how is the question?
Thanks for your help.
June 17th, 2010 at 8:25 am
Hi it would be great if you can notifiy me after post your new article
July 19th, 2010 at 6:22 pm
Hi Waldek,
I am not able to FormatDateTime function of the ddwrt namespace. I get an "Unable to display Web part…" error when I had the code. Could you tell me where I need to look to check for the namespace and add it if that is what the problem is?
Thanks
July 20th, 2010 at 7:22 pm
@Emma D: Did you add xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" to the < ?xsl:stylesheet?> directive of your XSLT file?
August 30th, 2011 at 12:06 am
[...] in edit mode or not? Originally I planned to create a really powerful solution injecting my custom data and functions as Waldek did for Content Query Web Part. Unfortunately there is a significant [...]
October 4th, 2011 at 4:31 pm
Dear Waldek,
Nice Post. I am using Sharepoint 2010. My Requirement is when i edit the content query webpart , i want to show other than three additional filters options 2 more additional filter. Please let me know which xsl file need to be modified for my requirement.
Thanks
Ranjani
October 10th, 2011 at 4:09 am
@Ranjani: XSL is for presentation only. If you want to add additional filters to the properties pane of the CQWP, you would have to subclass it and extend its ToolPartPane.
January 7th, 2012 at 8:43 pm
[...] Hier wird beschrieben, wie man in den XSLT-Templates (XSL file (ItemStyle.xsl, ContentQueryMain.xsl and/or Header.xsl)), die für das Rendering der Inhalte im CQWP verwendet werden mit Daten arbeiten kann, die man so erst einmal nicht zur Verfügung hat. Ein klassisches Beispiel ist das aktuelle Datum bzw. Uhrzeit. Dafür gibt es keine Variable im XSLT-Template. Man muss dazu das bestehende Content Query Webpart erweitern. Die Ermittelung des aktuellen Datums bzw. Uhrzeit findet dann im C# – Teil bereits statt und übergibt diese Daten an das XSLT-Template. Dies kann man natürlich mit allen Daten machen, die man benötigt. Egal ob irgendwelche Konstanten, (transformierte) SharePoint-Listendaten oder sonstige benötige Daten. In C# sind hier kaum Grenzen gesetzt. Extending Content Query Web Part with custom data [...]