Summary: SharePoint supports master pages since it is built on top of ASP.NET 2.0 and the master page used by all the publishing pages in any site can be configured allowing, therefore, different master pages per site. Individual publishing pages cannot be configured with their own master page, however. Nonetheless, there are ways to overcome this apparent limitation and assign a master page to a SharePoint publishing page dynamically.
As a former physics instructor at the University of Chicago Lab Schools, one of the questions I used to raise with my students dealt with the notion of change and universal constants. If you have ever studied physics you’ll probably recall a few such constants if I jog your memory a bit. The gravitational constant, G, Planck’s constant, h, and, perhaps most famously, the speed of light in a vacuum, c, are but a few. These are supposed to be unchanging over space and time hence the descriptor constant. It’s interesting, however, to contemplate the temporal dimension of these constants. The oldest of the constant’s I mentioned, G, is only as old as Isaac Newton’s work and that of Cavendish who followed; not even 400 years old. The universe is much older than that. A few universal "constants" could possibly be changing slightly and very, very slowly over time. If I’ve piqued your interest in this you can read more about changing physical constants via the link I’ve placed at the end of this blog (after reading the rest of this, please).
You however have only one constant in your environment, as the often-heard phrase and title of this blog suggests – change itself. Today’s business and technical environments and their associated requirements are ever-changing and at an ever-accelerating rate. Finding ways to allow your systems and business applications to adapt to and accommodate unending change is an ever-present challenge.
Microsoft SharePoint as an application provides a number of features that can assist you and your organization address this need. However, one occasionally encounters apparent limitations in SharePoint’s abilities in this regard. Often though, these are only apparent limitations. Research, careful design and experience with SharePoint as an application platform usually provide a number of possible solutions to these "limitations". One such apparent limitation is the inability to assign publishing pages in a given site different master pages.
Master Pages and SharePoint
ASP.NET 2.0 master pages provide the look and feel and standard behavior (e.g. navigation, header and footer links to global pages and so on) for all of the pages in a site. Together with content pages, they produce the output that is rendered for a given page. ASP.NET 2.0 allows static and dynamic assignment of master pages. The master page architecture provides the benefits of centralized management and maintenance of the pages controlling the navigation, globally displayed content and common look and feel of a site.
SharePoint is built on top of Microsoft ASP.NET 2.0 and as a result it supports master pages. Any SharePoint site with the publishing feature activated will have its publishing pages’ master page determined by the setting configured through the Site Settings page. The available master pages are listed in the Master Pages gallery.
SharePoint does not provide through its user interface (UI) a means of configuring pages within a site to use different sets of master pages although SharePoint Designer can be used to do so. Many organizations control the use of SharePoint Designer, however, because it is such a powerful tool. This limits what individual business-unit users of SharePoint can do and in the case of master pages effectively limits them to the default behaviors of SharePoint. If the requirement exists to use multiple master pages within a site, standard SharePoint provides no options other than SharePoint Designer.
SharePoint’s ability to assign master pages dynamically, a result of building upon ASP.NET 2.0, provides a solution to this apparent limitation.
There are a number of approaches that can be used to address a need for dynamic master pages. The design outlined below is just one. It makes use of three major features of SharePoint – content types, page layouts and SharePoint lists – and a custom .NET class. Additionally it is built with the assumption that most page requests will not be for pages whose masters are dynamic. If each page in a site were to have a master page assigned dynamically, the design would probably differ from that presented here.
Over the course of a few days Bob Moore and I collaborated on this work. I was responsible for the design discussed below and Bob who is all about dynamic SharePoint was responsible for actually writing the code, portions of which appear below.
Content Type(s)
Create a content type or set of content types for page layouts that will be used for pages requiring dynamic master pages. These content types should be created in their own category, Publishing Content Types: DynaMaster for example. The content types should exist at the Site Collection (SPSite) level and should derive from the Page content type as shown in Figure 1
Figure 1
Page Layouts
Pages requiring dynamic master pages should follow the normal SharePoint page request processing and use page layout pages. As shown in Figure 2, the folder PublishingLayoutsDynaMasters is located in the Features folder in the 12 hive. The folder structure within PublishingLayoutsDynaMasters mirrors that of the PublishingLayouts folder. The layout pages are sited therefore in the PageLayouts subfolder. These pages’ content type should be that of the Publishing Content Types: DynaMaster described earlier. The pages themselves should derive from a class that assigns the correct master page dynamically (DynaMaster Class below).
Figure 2
Keeping the layout pages used for dynamic assignment of master pages within the 12 hive as opposed to a page library within a site collection allows a globally accessible set of pages across all future site collections. This maximizes the potential reuse of these pages. If it is necessary to provide site-collection-specific layout pages, these can be uploaded to the collection’s gallery.
Page Layout and Master Page Association List
Create a custom SharePoint list, sited at the Site Collection’s top level site that will be used to associate a master page from the master page gallery with a page layout page. The list, Master Layout Association for example, is a custom list and should contain three columns as depicted in Figure 3 and Table 1.
Figure 3
|
Column Name |
Type |
Values and (Default) |
|
LayoutPage |
Single Line of Text |
Null |
|
Layout Page Scope |
Choice |
Global, Site Collection (Global) |
|
MasterPage |
Single Line of Text |
Null |
Table 1
DynaMaster Class
All of the layout pages used for dynamic assignment of master pages should inherit from a base class, DynaMaster, for example. This class, derived from the public class Microsoft.SharePoint.Publishing.PublishingLayoutPage, assigns the master page in the OnPreInit event. The class reads the Master Layout Association list to determine the name of the appropriate master page.
private string GetMasterPage()
{
SPSite site = SPControl.GetContextSite(Context);
SPWeb web = site.RootWeb;
string layoutName = GetLayoutPageName(web);
string masterFileName = GetMasterPageName(web, layoutName);
if (masterFileName == string.Empty)
{
throw new ApplicationException("Unassigend Master");
}
return masterFileName;
}
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
string masterPageFile = GetMasterPage();
if (masterPageFile == string.Empty)
{
throw new ApplicationException("Masterfile name is null");
…
}
else
this.MasterPageFile = masterPageFile; ;
}
There are a number of best practices you should follow in writing the code for this class. The class, for example, should default to the configured master page for the site if it is not possible to determine the name of the associated master page. This could happen if either the layout page was not listed in the Master Layout Association list or the MasterPage column is null on inspection. Other errors associated with the inability to assign a master page should also default to loading the configured master page. These practices ensure the content page loads even if an associated master page could not be located or loaded and prevent unnecessary exceptions from being thrown. Even so, you should write this information to the exception or event log according to your project’s guidelines.
If you want to make the name of the list read by the class or other aspects of this design configurable, there a number of ways to do so, including the use of configuration elements in the web.config file.
Final Notes
There are many benefits to the design presented here.
First, business-unit users have the ability to use multiple master pages in a given site without having to use SharePoint Designer. Some organizations will find this of great benefit. As important is the fact that this association can be done through a SharePoint list, something familiar to business-unit users. SharePoint Designer will be a less familiar tool even where its use is not strictly controlled.
Second, the ability to use dynamically a given master page for many different types of content pages greatly leverages the potential reach of a master page and the effort required for its initial creation.
Third, the fact that all layout pages used for dynamic master page association are derived from a class that extends the SharePoint PublishingLayoutPage class means that future master page and layout page use in a dynamic environment can evolve without the need for additional code development. Once written, tested and deployed the assembly need not be further modified to support new page layouts and master pages.
Oh yes, I promised a link about changing physical constants: Inconstant Constants
