In part 1 I described why a developer might choose to use a control adapter for branding out of the box SharePoint web parts.  In part 2 I showed how to create a control adapter and how you can deploy it to work with SharePoint.   In this final post for the series I will show an easier way for integrating control adapters into your SharePoint environment.

As you saw in part 2 the primary way to configure a control adapter is by adding a .browser file to your web applications app_browsers folder.  Ensuring that the file is created properly and deployed to all of the web front ends can be a complex and sometimes painful process.   An easier method is to add a little bit of code in your custom master page file.   Of course I am assuming here that since we are discussing branding you do have a custom master page with a code behind file.

To help attach a control adapter to a specific control type we will use a static helper method shown below.   This method should be placed in either a utility class or right within your custom master page class.   For the Destination Oakland site I placed it right within the custom master page class.

       private static void AddControlAdapterToType<T>(Type controlType) where T : ControlAdapter, new()
       {
           if (controlType == null)
           {
               throw new ArgumentNullException("controlType", "This argument can not be null!");
           }

           var adapters = HttpContext.Current.Request.Browser.Adapters;
           var key = controlType.AssemblyQualifiedName;
           if (!adapters.Contains(key))
           {
               var adapter = typeof(T).AssemblyQualifiedName;
               adapters.Add(key, adapter);
           }
       }

We will use this helper method in the constructor of the master page class to bind our custom adapter to specific controls.   Below is an example from the Destination Oakland web site.

public DestinationOaklandMaster()
{
    //Add our custom branding control adapter to brand the OOB web parts
    AddControlAdapterToType<BrandingAdapter>(typeof(Microsoft.SharePoint.WebPartPages.ContentEditorWebPart));
    AddControlAdapterToType<BrandingAdapter>(typeof(Microsoft.SharePoint.WebPartPages.ImageWebPart));
    AddControlAdapterToType<BrandingAdapter>(typeof(Microsoft.SharePoint.WebPartPages.ListViewWebPart));
    AddControlAdapterToType<BrandingAdapter>(typeof(Microsoft.SharePoint.WebPartPages.PageViewerWebPart));

    this.Load += new EventHandler(Page_Load);
}

The code in the constructor of the DestinationOaklandMaster class binds my custom control adapter class “BrandingAdapter” to 4 different out of the box SharePoint controls.    I find binding control adapters to controls using this method much more simpler than creating and deploying a .Browser xml file on all of the SharePoint web front ends.

As you have seen through this series of posts, branding out of the box SharePoint controls can be made easier by using custom control adapters.   Remember that anytime you introduce more code into your environment you could potentially see a performance impact.   In the case with Destination Oakland I saw no noticeable impact on the performance of the server when using a single custom control adapter bound to the 4 different out of the box SharePoint controls.