Passing custom arguments to the content query web part

We had a requirement to access the parameters entered by a content author/administrator in the tool pane of the content query web part (CQWP) to in the item style xslt template.

For this we decided to extend the functionality of the CQWP by sub-classing it. We included additional input fields to the tool pane by creating a new tool part class and added out custom tool part class to the out of the box tool pane of the CQWP.

To make the parameters entered in the tool part to be accessible in the ItemStyle.xsl we have to override the ModifyXsltArgumentList method of the CQWP.

protected override void ModifyXsltArgumentList(ArgumentClassWrapper argList)

{

base.ModifyXsltArgumentList(argList);

argList.AddParameter("yourparametername", "namespace", value);

}

Now the parameter can be accessed in the contentquerymain.xsl as a parameter.

<xsl:param name="cbq_isgrouping" />

<xsl:param name="cbq_columnwidth" />

<xsl:param name="Group" />

<xsl:param name="GroupType" />

<xsl:param name="cbq_iseditmode" />

<xsl:param name="cbq_viewemptytext" />

<xsl:param name="SiteId" />

<xsl:param name="WebUrl" />

<xsl:param name="PageId" />

<xsl:param name="WebPartId" />

<xsl:param name="FeedPageUrl" />

<xsl:param name="FeedEnabled" />

<xsl:param name="SiteUrl" />

<xsl:param name="BlankTitle" />

<xsl:param name="BlankGroup" />

<xsl:param name="UseCopyUtil" />

<xsl:param name="DataColumnTypes" />

<xsl:param name="ClientId" />

<xsl:param name="yourparametername" />

You can access the parameter now in the ItemStyle.xsl as follows:

<xsl:value-of select="$yourparametername"/>

Content deployment retry configuration

Only a part of the Content Deployment configuration settings are configurable through the central administration user interface, some of the settings have to be done in the web.config of the central administration website while others can only be accessed through the API.

The settings that can be configured through the web.config are discussed here. These settings relate to the Export phase of the content deployment process.

Options that can be configured through the central administration web configuration:

RetryOption: When content deployment jobs are executed in parallel or if content authoring is in progress when the job is running you may encounter many random exceptions. This is an enumeration ExportRetryOption.

The possible values for RetryOption include:

None (0) - default

SkipFailedWebs (1)

SimpleRetry (2)

Note: The enumeration is marked as internal and hence is not exposed through the API.

ExportRetries: This is used in parallel with the RetryOption. This is a number indicating the number of times the content export will retry before throwing up an error. Possible values are 1-999.

A more detailed explanation is described in Part 3 of the series on content deployment by Stefan Gobner.

http://blogs.technet.com/stefan_gossner/archive/2009/11/02/content-deployment-the-complete-guide-part-3-configuration.aspx

Note: These settings are part of the build 12.0000.6315.5000 or later.

PublishingLayoutPage,WebPartPage and custom Master pages

Page Layouts form an essential part of any Web Content Management (WCM) site built on MOSS 2007.

Page layouts when combined with master pages; define the layout of the page rendered. They also define the editable regions of the page, usually implemented by web parts and Meta data (Field controls) associated with the page.

Let us consider the base class from which the page layouts in any publishing site inherit from, the

Microsoft.SharePoint.Publishing.PublishingLayoutPage class. If we see any of the out of the box page layouts that SharePoint provides, we can see that they all inherit from the PublishingLayoutPage class.

Going a bit deeper into the implementation of the PublishingLayoutPage class, the documentation on msdn indicates the inheritance hierarchy of the class as follows:

System.Object

System.Web.UI.Control

System.Web.UI.TemplateControl

System.Web.UI.Page

Microsoft.SharePoint.WebPartPages.WebPartPage

Microsoft.SharePoint.Publishing.PublishingCachablePage

Microsoft.SharePoint.Publishing.PublishingLayoutPage

Source : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.publishinglayoutpage.aspx

So there is the PublishingCachablePage that separates the Microsoft.SharePoint.WebPartPages.WebPartPage which is the class all the pages in WSS derive from and the PublishingLayoutPage.

As we know if we derive out page layout from the PublishingLayoutPage, the master page for the layout is taken from the Site Master Page settings of the current site; this is an implementation of the PublishingLayoutPage class, using a reflector:

[PermissionSet(SecurityAction.Demand, Name="FullTrust")]

public class PublishingLayoutPage : PublishingCachablePage

{

// Methods

protected override void OnPreInit(EventArgs e)

{

base.OnPreInit(e);

SPContext current = SPContext.Current;

if (current == null)

{

SPException exception = new SPException(Resources.GetString("ErrorInvalidSPContextCurrent"));

ULS.SendTraceTag(ULSTagID.tag_7ob3, ULSCat.msoulscat_CMS_Publishing, ULSTraceLevel.Unexpected, "PublishingLayoutPage.OnPreInit(): Exception: SPContext.Current is null");

throw exception;

}

SPWeb web = current.Web;

this.MasterPageFile = web.CustomMasterUrl;

}

}

If you want to add new functionality to your publishing page layouts you can extend the PublishingLayoutPage class. This is a good post that describes how this can be achieved:

http://blogs.msdn.com/jannemattila/archive/2007/04/14/adding-functionalities-to-pages-by-inheriting-publishingpagelayout.aspx

If you want to specify a custom master page for more than one page layout to be used in a specific site you can override the OnPreInit method of the PublishingLayoutPage class and set the this.MasterPageFile property appropriately.