Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

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

share|improve this answer
    
How can we know WebPartId if we add this web part through UI and this property is dynamically assigned? –  Alexander Jan 29 '13 at 12:33
    
Good question, it seems in that case WebPartId could not be used. –  Vadim Gremyachev Jan 30 '13 at 22:19
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.