A master page enables us to put the common layout code in a single file and have it visually inherited in all of the content pages. In a sentece, A master page contains the overall layout for your site. All other Content pages can inherit the appearance of a master page, and place their own content where the master page has defined a ContentPlaceHolder control. Although this has the effect of providing a form of visual inheritance, it’s not really implemented with inheritance in an OOP sense — instead, the underlying implementation of master pages is based on a template model.
An example is worth a thousand words, so let's see how this concept turns into practice. A master page has a .master extension and is similar to a user control under the covers. The following is some code for a master page that contains some text, a header, a footer, and defines a ContentPlaceHolder control between the two:
<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs"
Inherits="MasterPage" %>
<html>
<head id="Head1" runat="server">
<title>TheBeerHouse</title>
</head>
<body>
<div id="header">The Beer House</div>
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
<div id="footer">Copyright © 2008 Nicholas Berardi</div>
</body>
</html>
As we can see, it is extremely similar to a standard page, except that it has a @Master directive at the top of the page instead of a @Page directive, and it declares one or more ContentPlaceHolder controls where the .aspx pages will add their own content. The master page and the content page will merge together
at runtime — therefore, because the master page defines the common contents and tags, we can easily guess that the content pages must not define them again. Content pages will only define the content for the master’s ContentPlaceHolder controls, and nothing else. The following extract shows an example of a content page:
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true"
CodeFile="MyPage.aspx.cs" Inherits="MyPage" Title="The Beer House - My Page" %>
<asp:content contentplaceholderid="MainContent" id="MainContent" runat="Server">
My page content goes here...</asp:content>
The first key point is that the @Page directive sets the MasterPageFile attribute to the virtual path of the master page. The content is placed into Content controls whose ContentPlaceHolderID must match the ID of one of the ContentPlaceHolder controls of the master page. In a content page, we can’t place anything but Content controls, and other ASP controls that actually define the visual features
must be grouped under the outermost Content controls. Another point to note is that the @Page directive has a new attribute, Title, which allows us to override the value specified in the master page’s <title> metatag. If we fail to specify a Title attribute for a given content page, the title specified on the master page will be used instead.
The figure below provides a graphical representation of the master page feature:
When we edit a content page in Visual Studio, it properly renders both the master page and the content page in the form designer, but the master page content appears to be "grayed out". This is done on purpose as a reminder to us that we can’t modify the content provided by the master page when we’re editing a content page.
It is important to point out that our master page also has a code-behind file that
could be used to write some C# properties and functions that could be accessed in the .aspx or code-behind files of content pages.
When we define the ContentPlaceHolder in a master page, we can also specify the default content for it, which will be used in the event that a particular content page doesn’t have a Content control for that ContentPlaceHolder. Here is a snippet that shows how to provide some default content:
<asp:ContentPlaceHolder ID="MainContent" runat="server">
The default content goes here…
</asp:ContentPlaceHolder>
Default content is helpful to handle situations in which we want to add a new section to a number of content pages, but we can’t change them all at once. We can set up a new ContentPlaceHolder in the master page, give it some default content, and then take our time in adding the new information to the content pages — the content pages that haven’t been modified yet will simply show the default content provided by the master.
The MasterPageFile attribute at the page level may be useful if we want to use different master pages for different sets of content pages. If, however, all pages of the site use the same master page, it’s easier to set it once for all pages from the web.config file, by means of the
<pages masterPageFile="~/Template.master" />
If we still specify the MasterPageFile attribute at the page level, that attribute will override the value in web.config for that single page.
0 comments:
Post a Comment