We all know Content Query Web Part (CQWP) – probably the greatest Web Part provided with SharePoint Server that allows you to build dynamic content aggregations in a matter of minutes. CQWP is known not only for its great performance but also for its flexibility and extensibility capabilities. In SharePoint Server 2010 Content Query Web Part introduces even more functionality among which the slots – a cool feature that allows you to create semantic and reusable templates. And while creating new templates became as simple as it was never before there is one thing that you should keep in mind while working with Content Query Web Part slots.

Slots – and it’s not about Vegas

Slots are new capability of Content Query Web Part introduced with SharePoint Server 2010. Slots allow you to create semantic and reusable presentation templates. Where you had to cast some magic spells in Office SharePoint Server 2007 to get custom Item Style templates work with your custom Content Types, you can benefit of slots in SharePoint Server 2010 and create new Item Style template in the matter of minutes.

How it works?

First of all you start off by creating a new Item Style template just as you would with Office SharePoint Server 2007 – nothing new here. But then the magic happens. As soon as you pick your custom Item Style template in the Web Part properties, CQWP parses the selected template and generates slots for it: every @SomeProperty becomes a slot:

<xsl:template name="DetailedOverview" match="Row[@Style='DetailedOverview']" mode="itemstyle">
    <xsl:variable name="SafeLinkUrl">
      <xsl:call-template name="OuterTemplate.GetSafeLink">
           <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
      </xsl:call-template>
  </xsl:variable>
  <xsl:variable name="DisplayTitle">
      <xsl:call-template name="OuterTemplate.GetTitle">
          <xsl:with-param name="Title" select="''"/>
          <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
          <xsl:with-param name="UseFileName" select="1"/>
      </xsl:call-template>
  </xsl:variable>
  <p>
      <strong><xsl:value-of select="$DisplayTitle"/></strong><br />
      <xsl:value-of select="@Author"/>, <xsl:value-of select="@Date"/>
  </p>
  <p>
      <xsl:value-of select="@RollupImage"/>
      <xsl:value-of select="@Details"/>
  </p>
  <p>
      <a href="{$SafeLinkUrl}">Read more</a>
  </p>
</xsl:template>

will generate the following slots:

You can now bind one or more fields to every slot by providing their display names. If the value of the first field is empty, CQWP will look for the value of the next one. This is extremely useful when aggregating items of different Content Types.

Using slots allows you to create reusable Item Style templates. Because the binding with the fields is being done through Web Part’s settings, you can reuse your existing templates across different projects what allows you to standardize your solutions and simplify the maintenance.

There is however one thing about slots that doesn’t work as you would expect it to…

Inconvenient description

Probably one of the most commonly used content aggregation templates is the one where you display the title, some short description and a link that takes the visitor to the full content.

In such overview the title is being retrieved from the Title field and the short description from the Description (internal name: Comments) field. So how come that it doesn’t work?! No matter if you provide the display name (Description), Internal Name (Comments) or Display Name and the Group Name (Comments [_Hidden]) you won’t see the description:

It turns out that there is an “undocumented feature” in SharePoint 2010 and it has to do with how the fields are being bound to the slots.

The problem

Right after you enter the names of the fields and hit the Apply button, the Content Query Tool Part starts resolving the bindings. For every field it asks the Content Query Web Part to return the binding information. Content Query Web Part uses for this purpose the list of all Site Columns and this is where the problems begin.

If you request the binding information for the Site Column with display name Description the CQWP will return:

{3f155110-a6a2-4d70-926c-94648101f0e8},Description,Note;

which is the Description field indeed, however it is not the Comments field which we know from the Page Content Type (ID: 9da97a8a-1da5-4a77-98d3-4bc10456e700).

If you however look further at the Content Types you will see that the Description field is in fact called Comments:

If you however request a binding for the Comments field you will still get a binding different than the one you need:

{691b9a4b-512e-4341-b3f1-68914130d5b2},ShortComment,Text;

It turns out that there are three columns with display name Comments: ShortComment, Comments and _Comments. You could try to solve this problem by adding the group name, such as:

Comments [_Hidden]

which allows you to distinguish between different Site Columns with the same display name. The problem is however that there are actually two Site Columns called Comments in the _Hidden group: ShortComment and Comments. And since the ShortComment Site Column is being added first to the array it gets picked up by the Content Query Web Part and as a result you end up with an invalid binding.

The workaround

You could work around this issue by fixing the binding generated by the Content Query Web Part. After configuring the CQWP, you would export it and modify the value of the DataMappings property.

By setting the value to the right ID, internal name and type, you could make the CQWP to work as expected. However as soon as someone edits the Content Query Web Part and hits the Apply button, your binding will be broken again. Not much of a reliable solution, is it?

Real solution?

In order to really deal with this challenge you have two options.

First of all you can change the display name of either the ShortComment or the Comments column. Because SharePoint uses ID’s and/or internal names for references this should work properly. The risky part is that both columns are standard SharePoint columns and you never know if there is something that relies on the display name. As a result, while fixing one issue, you might just be causing another.

Another solution is not to use the standard Comments field at all and create a custom Site Column which you will use for including short description. In this approach you can be sure that nothing else will break as you are using your own custom Site Column. The downside is that you cannot use the standard field that is already there.

Summary

Content Query Web Part in SharePoint Server 2010 introduces new concepts called slots. Using slots you can easily create semantic and reusable Item Style templates. While slots simplify working with Content Query Web Part you should consider which Site Columns you use for storing content as they might conflict with standard columns provided with SharePoint.

Technorati Tags: SharePoint 2010,SharePoint Server 2010