Basic XSLT: Using contentquerymain.xsl for several CQWP's

Question

Is there anyway of specifying a match condition to determine which CQWP is being 'passed through' the XSLT in main.

Ultimately, I want to have a main.xslt file to serve several CQWP's but all must have a slightly different bit of markup.

In item style - I can evaluate the style like so:

<xsl:template name="News" match="Row[@Style='News']" mode="itemstyle">
       ...
      </xsl:template>

But if I attempt this in main.xslt it's never true:

<xsl:template match="/">
    <xsl:call-template name="OuterTemplate" />
  </xsl:template>

<xsl:template name="OuterTemplate">
<div>
      <xsl:attribute name="class">
        <xsl:if test="Row[@Style='News']">
          TEST
        </xsl:if>  
      </xsl:attribute>
</div>
 </xsl:template>

I'm assuming that at a 'main' level I have no access to the Row @Style so is there anything else I can use?

Answer 1

Several options are available for this purpose:

OOTB WebPartId parameter for CQWP

This parameter allows to identify instance of CQWP on page.

Pros: No code solution
Cons: Not appropriate for deployment scenarios (web part id is generated during creation of CQWP instance)

For example:

<xsl:choose>
    <xsl:when test="$WebPartId = 'c7636893-cd8b-4d85-b8e7-f9659d149ce3'">
        <!-- Specific CQWP processing goes here -->
    </xsl:when>
    <xsl:otherwise>
        <!-- Another CQWP processing goes here -->
    </xsl:otherwise>
</xsl:choose>

---

Extend (subclass) CQWP

public class ContentByQueryWebPartEx : ContentByQueryWebPart
{



    protected override void ModifyXsltArgumentList(ArgumentClassWrapper argList)
    {
        argList.AddParameter("cbq_instanceId", string.Empty, CBQInstanceId);
        base.ModifyXsltArgumentList(argList);
    }


    /// <summary>
    /// Return the tool panes that configure this <see cref="T:Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart"/> object..
    /// </summary>
    [SharePointPermission(SecurityAction.Demand, ObjectModel = true)]
    public override ToolPart[] GetToolParts()
    {
        return new ToolPart[3]
                   {
                       new ContentByQueryToolPart(),
                       new WebPartToolPart(),
                       new CBQToolPart()   //Custom Tool Part 
                   };
    }


    #endregion



    [Personalizable(PersonalizationScope.Shared),WebBrowsable(true)]
    public string CBQInstanceId { get; set; }




    #endregion
}

After referencing it XSLT

<xsl:param name="cbq_instanceId" />

it could be used in XPath queries

Pros: Web part instance parameter could be specified during deployment process

Cons: Implementation is required

Extend (subclass) CQWP with parameter binding

public class ContentByQueryWebPartEx : ContentByQueryWebPart
    {

        /// <summary>
        /// Return the tool panes that configure this <see cref="T:Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart"/> object..
        /// </summary>
        [SharePointPermission(SecurityAction.Demand, ObjectModel = true)]
        public override ToolPart[] GetToolParts()
        {
            return new ToolPart[3]
                       {
                           new ContentByQueryToolPart(),
                           new WebPartToolPart(),
                           new CBQToolPart()   //Custom Tool Part 
                       };
        }


        #endregion



        [Personalizable(PersonalizationScope.Shared),WebBrowsable(true)]
        public string CBQInstanceId { get; set; }




        #endregion
    }

After specifying ParameterBindings property in web part

<ParameterBinding Name="cbq_instanceId" Location="WPProperty(CBQInstanceId)" />

and referencing it XSLT

<xsl:param name="cbq_instanceId" />

it could be used in XPath queries:

<xsl:choose>
    <xsl:when test="$cbq_instanceId = 'ABC'">
        <!-- Specific CQWP processing goes here -->
    </xsl:when>
    <xsl:otherwise>
        <!-- Another CQWP processing goes here -->
    </xsl:otherwise>
</xsl:choose>

Pros: Web part instance parameter could be specified during deployment process, no code solution

Cons: Implementation for custom properties is required

Answer 2

I think that you can try to specify condition in the web part properties and use this approach. Look at the answer of Andrey Markeev.