Monthly Archives: August 2008

Portal Navigation Properties Feature

Today my colleague Harmjan Greving pointed me to the Portal Navigation Properties Feature. I had never encountered this one before and as it turns out it is surprisingly undocumented by Microsoft.

So what does it do? Well, it’s a feature that comes with MOSS 2007 (unfortunately it isn’t included with WSS 3.0) that enables you to define per-site navigation settings in a declarative way. Until now I always used to write custom API code for this, that I executed from a feature receiver or a custom site provisioning provider.

The Portal Navigation Properties Feature itself is actually very simple. It contains no elements, but is only used to trigger the Microsoft.SharePoint.Publishing.NavigationFeatureHandler feature receiver, which does the real work, based on properties you specify. It is typically used from within a site definition file (ONET.XML), like this:

    <Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
        <!-- Portal Navigation Properties Feature -->
        <Properties xmlns="">
            <Property Key="InheritGlobalNavigation" Value="True"/>
            <Property Key="InheritCurrentNavigation" Value="True"/>
            <Property Key="IncludeSubSites" Value="True" />
            <Property Key="IncludePages" Value="False" />
            <Property Key="OrderingMethod" Value="Automatic"/>
            <Property Key="AutomaticSortingMathod" Value="CreatedDate"/>

Using Reflector I found out the following properties can be used with this feature:

Property Valid Values
IncludeInCurrentNavigation True / False
InheritGlobalNavigation True / False
InheritCurrentNavigation True / False
ShowSiblings True / False
IncludeSubSites True / False
IncludePages True / False
OrderingMethod Automatic
AutomaticSortingMathod 1 Title
SortAscending True / False

1 Please note the awful spelling error in “AutomaticSortingMathod”. Ofcourse this should have been “AutomaticSortingMethod”, but apparently someone at Microsoft forgot to run the spell checker over his/her code 😉

Building a SPQuery ViewFields string

If you’re querying SharePoint content using a CAML query from code it’s a good habit to always populate the SPQuery instance’s ViewFields property. Otherwise the returned SPListItem instances might not contain any data for certain fields and throw an exception when you try to access those fields.

Specifying ViewFields involves creating a string of CAML FieldRef elements. For instance if we want our query to return items that contain data for the Title, Created and ID field we use this:

   1: <FieldRef Name='Title'/><FieldRef Name='Created'/><FieldRef Name='ID'/>

As you can see there’s some overhead of boilerplate markup involved. I’ve written a small piece of code that I always use to make my life a little easier. Today I happened to post this code in a reply I wrote on the MSDN forums and also decided to submit it as Community Content to the official SPQuery docs on MSDN. Then I thought I might as well share it with you here. So here it is:

   1: public static string BuildViewFieldsXml(params string[] fieldNames)
   2: {
   3:     const string TEMPLATE = @"<FieldRef Name='{0:S}'/>";
   4:     StringBuilder sb = new StringBuilder();
   5:     foreach (string fieldName in fieldNames)
   6:     {
   7:         sb.AppendFormat(TEMPLATE, fieldName);
   8:     }
   9:     return sb.ToString();
  10: }
  12: // Use it like this:
  13: SPQuery query = new SPQuery();
  14: query.ViewFields = BuildViewFieldsXml("Title", "Created", "ID");
  16: // Note that you can specify a variable amount of string parameters, i.e.
  17: query.ViewFields = BuildViewFieldsXml("Title", "Created", "ID", "Author", "Gender");

Yeah, you’re right. This piece of code isn’t exactly rocket science. But you might appreciate it anyway 🙂