Organize your Feature Receivers

At imason I have done a lot of work with SharePoint feature receivers. As the size of solution grows, so does the number and complexity of feature receivers. This makes developers treat installation logic that lives inside feature receivers with necessary care. It is no longer some dirty through-away code and all the proven architecture techniques perfectly apply to it as well. See the full post here.

Toronto SharePoint Code Camp 2009 - Great Venue, Great Organization

I was presenting at the Toronto SharePoint Camp for the first time last weekend. The event has exceeded my expectations by all accounts. The venue and the organization were excellent, and the great turn-out has demonstrated a strong interest in SharePoint and growing developer community around it. Great thanks to Ed Musters and other organizers for this great event!

My topic was named "Effective Deployment of SharePoint Publishing Sites", and was largely based on the idea of authoring a custom XML document representing site hierarchy, including variations, sites, pages and web parts. Deployment automation logic would then consume this document and create actual site hierarchy from it - something I have been blogging about earlier. I have also touched on a quite interesting subject of how to assess the worthiness of an upfront effort investment into deployment automation. You can download my presentation here.

Show Alternating Rows in Content Query Web Part

Often you need to display alternating rows in a Content Query Web Part (CQWP), so that for example you get a record on a white background, then a record on a gray background, then on white again etc. Yes, you can create a special “index” column in your source content type and based on its value determine if a given row is odd or even.

There is a better way however: from within your ItemStyleTemplate.xsl you can know the position of the current node, which you can always translate into the knowledge of whether the current row is odd or even:

<xsl:template name="AlternatingItems" match="Row[@Style='AlternatingItems']" mode="itemstyle">
        <xsl:variable name="CurPosition" select="count(./preceding-sibling::*)" />
        <xsl:variable name="AlternatingCssClass">
           <xsl:choose>
                <xsl:when  test="($CurPosition mod 2 = 0)">
                     <xsl:value-of select="'CssClassAlt1'" />
                </xsl:when>
                <xsl:otherwise>
                     <xsl:value-of select="'CssClassAlt2'" />
                </xsl:otherwise>
           </xsl:choose>
        </xsl:variable>
        … the rest of the template

On a related but different topic, in order to have a field exposed to your XSL file as an attribute of the Row XML element you typically need to export the CQWP to a file then edit its property named CommonViewFields as perfectly explained by Heather Solomon here.

The only thing calling for some expansion after reading this blog post is how to know which field name and which type name exactly to feed into the CommonViewFields property. The definitive source of the information about which fields are there and which are their types is located in here:

%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\fields\fieldswss.xml

Each field in this XML file has a Name attribute and a Type attribute, their values can be fed into the CommonViewFields property of your CQWP. Ideally we want to be able to list all applicable fields based on currently selected options for the query, but this would require extending the web part itself…