Introduction
Visual Inheritance is one of the most challenging and often required features that is needed in the development of portal applications of late. In order to achieve the same in portal applications, this poses a challenge, and some considerable amount of effort is involved to implement this functionality. Windows SharePoint Services 2.0 did not provide any feature through which users could "templatize" their sites. In other words there were no truly generic features or approaches through templates could be standardized for the entire site.
Need For Templatization of Entire Site
There is definitely a need for templatization of entire sites because while developing portals, we come across scenarios wherein there need to be common headers, footers and menus that are common throughout the entire site. This definitely gets a lot of importance when we are dealing with sites which contain dynamic content. In such sites, each page is different from another page only through content; the rest (appearance) remains the same across the entire site. Again, in such sites, there is a need for templatization of the entire site.
So, from the above explanation, what we understand is that there is a requirement or a feature through which templatization of the entire site would be possible.
ASP.NET 2.0
ASP.NET 2.0 has introduced a powerful page templating feature called Master Pages. Through the Master Page, it is possible to define a standard page layout for the entire site with elements such as a banner, common headers, common footers, controls and menus. I just want to point out that Master Pages are implemented in much the same way how custom template mechanisms work in ASP.NET 1.1, but in ASP.NET 2.0 there is the designer support from Visual Studio 2005.
Master Pages
A Master Page is a template through which a standard template for the entire site can be defined. This standard template can contain elements that are common for the entire site like common headers, common footers, banners, common links etc.
Another approach to define Master Pages would be "A Master Page is an ASP.NET file with extension .master (for example, MySite.master) with a predefined layout that can include static text, HTML elements, and server controls."
Master Pages are identified by the "@ Master" directive that replaces the "@ Page" directive that is used for ordinary .aspx pages. The following is the code snippet that shows how the Master Page directive is used:
' VB.Net:
<%@ Master Language="VB" %>
//C#:
<%@ Master Language="C#" %>
Master Pages consist basically of two conceptual elements. They are as follows:
Master Pages
As already defined above, a Master Page is essentially a standard ASP.NET page except that it uses the extension of .master and a <%@ master %> directive instead of <%@ page %>. This Master Page file serves as the template for other pages, so typically it will contain the top-level HTML elements, the main form, headers, footers, and such. Within the Master Page, you add instances of the ContentPlaceHolder control at locations where you want Content Pages to supply page-specific content.
Creating a Master Page:
<% @ Master Language="VB" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head runat="server" >
<title>This is the Master page title</title>
</head>
<body>
<form id="MyForm1" runat="server">
<table>
<tr>
<td><asp:contentplaceholder id="Main" runat="server" /></td>
<td><asp:contentplaceholder id="Footer" runat="server" /></td>
</tr>
</table>
</form>
</body>
</html>
<%@ Master Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head runat="server" >
<title>This is the Master page title</title>
</head>
<body>
<form id="MyForm1" runat="server">
<table>
<tr>
<td><asp:contentplaceholder id="Main" runat="server" /></td>
<td><asp:contentplaceholder id="Footer" runat="server" /></td>
</tr>r>
</table>
</form>
</body>
</html>
In the above code snippet, apart from using static text and controls, it is also possible to add content depending on a page. This can be achieved by using the ContentPlaceHolder keyword. In the above sections, I was mentioning about sites that require creating dynamic content depending on each and every page. This functionality can be achieved using the ContentPlaceHolder keyword. A ContentPlaceHolder control defines a relative region for content in a master page, and renders all text, markup, and server controls from a related Content control found in a content page.
In the above example, the ContentPlaceHolder's are "Main" and "Footer".
Content Pages
Content Pages are ordinary .aspx files that specify an associated Master Page in their page directive using the "masterpagefile" attribute. You can call it something like a derived class (the base class being the Master Page Template). The main purpose of Content Pages is to supply content for the inherited Master Page template. Due to this reason, the Content Pages must contain only instances of the Content controls.
It must also be noted that the Content controls present in the Content Pages must map to the specific ContentPlaceHolder control defined in the Master Page which the content page refers to.
Creating a Content Page
<%@ Page Language="VB" MasterPageFile="~/Master.master"
Title="Content Page 1" %>
<asp:Content ID="Content1" ContentPlaceHolderID="Main" Runat="Server">
Will contain the Main content.
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="Footer" Runat="Server" >
Will contain the Footer content.
</asp:content>
<%@ Page Language="C#" MasterPageFile="~/Master.master"
Title="Content Page 1" %>
<asp:Content ID="Content1" ContentPlaceHolderID="Main" Runat="Server">
Will contain the Main content.
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="Footer" Runat="Server" >
Will contain the Footer content.
</asp:content>
It is to be noted that the @ Page directive will bind the content page to the specified master page and the contents of the content page will be merged into the Master Page. Also note that there is no other markup outside the Content control (I have already mentioned above stating the main purpose of Content Pages is to display content. That is the reason why there are no other markups present in the above mentioned Control Page example.).
Master Pages in Windows SharePoint Services 3.0
Now the question arises, what kind of role do Master Pages play in Windows SharePoint Services 3.0 (expected to be released by December 2006). It is worth noting that Windows SharePoint Services 3.0 was redesigned from scratch to accommodate or embrace the Master Page infrastructure provided by ASP.NET 2.0. Every site in Windows SharePoint Services 3.0 is provisioned with a special catalog known as the Master Page Gallery containing a master page known as default.master.
This master page defines a common layout for every site's home page (Default.aspx) as well as standard Windows SharePoint Services form pages associated with lists and document libraries (for example: AllItems.aspx, NewItem.aspx). The master page layout includes standard Windows SharePoint Services menus and navigation controls.
It is possible to customize just the Master Page for a site while leaving the content page uncustomized. Similarly it is possible to customize just one Content Page leaving the Master Page uncustomized. In case you want to discard the changes made either to the Master Page or to the Content Page, then the same can be done using browser-based UI of Windows SharePoint Services 3.0 or the Office SharePoint Designer 2007 which provides simple menu based options to discard the changes done.
Templates defined for the Master Page and the Content Pages are stored in the local file system of the front-end web server. Each site initially uses a ghosted (that is, an uncustomized version) of the master page template and the content page templates. Once they have been customized (that is, unghosted), the same is saved in the SQL Server database.
The Windows SharePoint Services 3.0 default master page contains several ContentPlaceHolder controls to enable easy customization to an individual content page. By default, Windows SharePoint Services 3.0 content pages uses the content placeholders defined in the following table. The following table describes the content placeholders contained in the Windows SharePoint Services default master page and what each of the placeholders represents on the page.
| Srl No | Content PlaceHolder | Description |
| 1 | PlaceHolderAdditionalPageHead
Bottom of Form | Additional content that needs to be within the <head> tag of the page, for example, references to script in style sheets
Bottom of Form |
| 2 | PlaceHolderBodyAreaClass
Bottom of Form | Additional body styles in the page header
Bottom of Form |
| 3 | PlaceHolderBodyLeftBorder
Bottom of Form | Border element for the main page body
Bottom of Form |
| 4 | PlaceHolderBodyRightMargin
Bottom of Form
| Right margin of the main page body
Bottom of Form |
| 5 | PlaceHolderCalendarNavigator
Bottom of Form | Shows a date picker for navigating in a calendar when a calendar is visible on the page
Bottom of Form |
| 6 | PlaceHolderFormDigest
Bottom of Form | The "form digest" security control
Bottom of Form |
| 7 | PlaceHolderGlobalNavigation
Bottom of Form | The global navigation breadcrumb
Bottom of Form |
| 8 | PlaceHolderHorizontalNav | Top navigation menu for the page |
| 9 | PlaceHolderLeftActions | Bottom of the left navigation area |
| 10 | PlaceHolderLeftNavBar | Left navigation area |
| 11 | PlaceHolderLeftNavBarBorder | Border element on the left navigation bar |
| 12 | PlaceHolderLeftNavBarDataSource | Data source for the left navigation menu |
| 13 | PlaceHolderLeftNavBarTop | Top of the left navigation area |
| 14 | PlaceHolderMain | Page's main content |
| 15 | PlaceHolderMiniConsole | A place to show page-level commands, for example, WIKI commands such as Edit Page, History, and Incoming Links |
| 16 | PlaceHolderNavSpacer | The width of the left navigation area |
| 17 | PlaceHolderPageDescription | Description of the page contents |
| 18 | PlaceHolderPageImage | Page icon in the upper left area of the page |
| 19 | PlaceHolderPageTitle | The page <Title> that is shown in the browser's title bar |
| 20 | PlaceHolderSearchArea | Search box area |
| 21 | PlaceHolderSiteName | Site name |
| 22 | PlaceHolderTitleAreaClass | Additional styles in the page header |
| 23 | PlaceHolderTitleAreaSeparator | Shows shadows for the title area |
| 24 | PlaceHolderTitleBreadcrumb | Main content breadcrumb area |
| 25 | PlaceHolderTitleInTitleArea | Page title shown immediately below the breadcrumb |
| 26 | PlaceHolderTitleLeftBorder | Left border of the title area |
| 27 | PlaceHolderTitleRightMargin | Right margin of the title area |
| 28 | PlaceHolderTopNavBar | Top navigation area |
| 29 | PlaceHolderUtilityContent | Extra content that needs to be at the bottom of the page |
| 30 | SPNavigation | Empty by default in Windows SharePoint Services. Can be used for additional page editing controls. |
| 31 | WSSDesignConsole | The page editing controls when the page is in Edit Page mode (after clicking Site Actions, then Edit Page) |
Summary
It is clearly understood that the Master Page concept solves many of the problems of creating and maintaining standard templates across the entire site. Master Page introduces the concept of Visual Inheritance which is a blessing for designing the UI for the entire site in a much more generic manner. Developers no longer have to build complicated control hierarchy-manipulating techniques in ASP.NET.
