Marking Up Master Pages

Marking Up Master Pages

To add a master page to a web project, right-click your web project in the Solution Explorer window, select Add New Item, and select the Master Page item type from the Add New Item dialog. The listing below shows a sample master page in source view.

Untitled Page

A master page looks very similar to an ASPX file, except a master page will have a .master file extension instead of a .aspx extension, and uses an @ Master directive instead of an @ Page directive at the top. Master pages will define the , , , and , tags. A new control, the ContentPlaceHolder control also appears in our master page. You can have one or more ContentPlaceHolder controls in a master page. ContentPlaceHolder controls are where we want our ASPX web forms to place their content.

Just like any ASPX form, our master page can contain code in a block, or in a code-behind file, and can respond to page lifecycle events. The MasterPage class (from the System.Web.UI namespace) derives from UserControl and will have all of the usual events: Init, Load, PreRender, etc. The following listing shows how weve added a Page_Load event handler to modify the color of the menu control on the page, and weve also added a property to allow setting and retrieving the text inside the footer.

Partial Class otc

Inherits System.Web.UI.MasterPage

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

If Not IsPostBack Then

Menu1.BackColor = Drawing.Color.LemonChiffon

End If

End Sub

Public Property FooterText() As String

Get

Return Footer.Text

End Get

Set(ByVal value As String)

Footer.Text = value

End Set

End Property

End ClassPlugging In Content

The ASPX web forms we use to put content into master pages are plain .aspx files, although with a few differences. When you add a new ASPX web form to a project youll have the option of associating the web form with a master page. Doing so will place a MasterPageFile attribute in the @ Page directive for the web form. The attribute points to the .master file youve selected (you can have multiple master pages in a web project). The source code below is for a default.aspx file using the otc.master master page we defined earlier.

mainContent

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Quisque auctor, dui a

accumsan faucibus, erat dolor rhoncus massa, a hendrerit nulla purus eu dui. Morbi

eget ligula. Proin sapien augue, sagittis vel, blandit sed, lobortis et, nulla.

Nullam laoreet blandit erat. Ut egestas. Lorem ipsum dolor sit amet, consectetuer

adipiscing elit. Pellentesque ut wisi at tellus placerat vestibulum. Aliquam at

lacus non justo vulputate suscipit. Quisque mattis, arcu sed tempus fermentum, diam

neque varius elit, vel eleifend nibh urna a pede.

sideContent

Donec hendrerit. Aliquam at massa. Pellentesque sed justo. Donec interdum ipsum

vitae nisl. Maecenas ac quam non lacus posuere convallis. Mauris nibh. Quisque mattis,

arcu sed tempus fermentum, diam neque varius elit, vel

mainContentLorem ipsum dolor sit amet, consectetuer adipiscing elit. Quisque auctor, dui a accumsan faucibus, erat dolor rhoncus massa, a hendrerit nulla purus eu dui. Morbi eget ligula. Proin sapien augue, sagittis vel, blandit sed, lobortis et, nulla. Nullam laoreet blandit erat. Ut egestas. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Pellentesque ut wisi at tellus placerat vestibulum. Aliquam at lacus non justo vulputate suscipit. Quisque mattis, arcu sed tempus fermentum, diam neque varius elit, vel eleifend nibh urna a pede.

sideContent

Donec hendrerit. Aliquam at massa. Pellentesque sed justo. Donec interdum ipsum vitae nisl. Maecenas ac quam non lacus posuere convallis. Mauris nibh. Quisque mattis, arcu sed tempus fermentum, diam neque varius elit, vel

A web form associated with a master page is called a content page. A content page may only contain markup inside of Content controls. If you try to place any markup or controls outside of the Content controls, youll receive a compiler error: Only Content controls are allowed directly in a content page that contains Content controls.

Each Content control in a content page maps to exactly one of the ContentPlaceHolder controls in the Master Page. You do not need to define a content control for every ContentPlaceHolder control in the master. If a Content control doesnt exist for a place holder, the master page will simply render the default content inside of the ContentPlaceHolder of the master page (we did not define any in this example).

The runtime examines the ID of each Content control and finds a ContentPlaceHolder with a matching ID. When the runtime finds the match it will take the markup and controls inside the Content control and insert them into the ContentPlaceHolder of the master page. Even though our Content controls in this example do not contain any server side controls, like GridView controls and Calendar controls, any ASP.NET control can appear inside the Content areas.

One benefit to working with master pages in the Visual Studio IDE is the built-in design support for master pages. The screen below shows our default.aspx form in a design time view. The Content controls are the only editable sections of the form. The master page markup displays in design view, but since we are editing default.aspx and not otc.master in the screen shot, the sections defined by the master page are un-editable and ghosted out. This gives designers and developers a clear idea of content versus the layout structure defined by the master page.

The second screen shot above shows our default.aspx web form in action. Weve used a .css style sheet (shown below) to position the tags on the page. The approach will give us a great deal of flexibility. We can make changes to the layout of the site simply by editing the CSS or master page, whichever makes the most sense for the change we need to make. In either case, we will never have to duplicate the s on any of our web forms, the layout is controlled entirely in the master page.The second screen shot above shows our default.aspx web form in action. Weve used a .css style sheet (shown below) to position the tags on the page. The approach will give us a great deal of flexibility. We can make changes to the layout of the site simply by editing the CSS or master page, whichever makes the most sense for the change we need to make. In either case, we will never have to duplicate the s on any of our web forms, the layout is controlled entirely in the master page. body

{

font-size: smaller;

}

#main

{

float: left;

width: 67%;

background: #fff;

border-right: 1px solid #000;

margin-right: 15px;

padding-bottom: 10px;

padding-right: 10px;

}

#footer

{

clear: both;

width: 100%;

text-align: center;

font-size: 10px;

padding: 3px;

border-top: 3px solid #333;

background-color: #cccc99;

}

#footer

{

clear: both;

width: 100%;

text-align: center;

font-size: 10px;

padding: 3px;

border-top: 3px solid #333;

background-color: #cccc99;

}

Programmatically Working With Master Pages

The MasterPage class derives from UserControl. The master page will inject itself as the top control in a pages control hierarchy by clearing the pages Controls array and adding itself to into the collection. Doing so includes all of the markup and controls defined inside the master page in the page's control tree. The master page can then walk the Content controls that existed in the web form and bring them back them into the control hierarchy in the appropriate locations. The master page injection happens after the PreInit event fires for a Page object, but before the Init event fires.This ordering of events outlined above is important if you want to programmatically set the master page to use for a web form with the MasterPageFile property. This property must be set in the PreInit event (or earlier), like the code below. One the master page has injected itself into the control hierarchy it is too late to try to set a new master page for the web form. If you try to set the MasterPageFile property after the PreInit event fires, the runtime will throw an InvalidOperationException.

Protected Sub Page_PreInit(ByVal sender As Object, ByVal e As EventArgs) Handles Me.PreInit ' we can select a different master page in the PreInit event

Me.MasterPageFile = "~/otc.master"End SubAnother way to interact with a master page is through the Master property of a page object. Lets say we needto get to the Footer property defined in our master page. There are two approaches to touchingthis property. The first is to use the Master property of the System.Web.UI.Page class, which returns a MasterPage reference. In order to get to the Footer property, though, we would have to cast the reference to our derived master page type, like the following code.

CType(Master, otc).FooterText = "New Footer Text"

A second approach, if you know the exact master page file your page will be using at runtime, is to let the ASP.NET page parser generate a strongly typed Master property by adding an @ MasterType directive to your ASPX file, as shown below.

The MasterType directive will instruct the runtime to add a new Master property to code-generated file for the page. The new property will return a reference matching the MasterType. With a MasterType directive in place for our web form, we don't need a cast. For more information on @ MasterType, see, MasterType in ASP.NET 2.0.Master.FooterText = "Simple!"URL Rebasing In Master PagesThe master page implementation outlined above has another consequence to watch for. Since the master page injects it's controls and markup intothe pages Controls array, any relative URLs in the master page markup may break.The browser will request the web form, not the master page, so all of the URLs will be relative to the web form. When the web form and master page are in different directories, relative URLs may point to the wrong location. To help alleviate relative URL problems, ASP.NET will rebase relative URLs for server-side controls in a master page. Rebasing will build the correct URL to the resource.

As an example, imagine we created our master page in the root directory of a web site, and we have an images subdirectory underneath the root. We might be tempted to add an image to our master page with the following markup.

The above URL will work as long as the web form using the master page is in the root directory. If we attach a web form in another subdiretory to the master page the image URL will break. One way to fix the brokenURL is to turn the HTML tag into a server side control by adding runat=server. Server side controls have their URLs rebased. Notice the tag in the master page has runat=server in place, this will rebase your style sheet links.

The following markup demonstrates what will work, and not work from a master page

My background is relative, and broken

My background works

My background is broken. URL rebasing doesn't work for embedded style, event

with server side control.

Nested Master Pages

You can write a content page that is itself a master page, allowing an arbitrarily deep nesting of master pages. This technique can be useful when your application is broken into sub-applications that need to inherit a common branded look but still be able to define their own customized layout template within the brand. The following listing shows a master page that would serve as a content page for our first master page example.

Notice we must obey the rules for a content page in this master page, that is, we can only define content inside of Content controls. The ContentPlaceHolders inside of these controls can then be filled in with web forms addressing the IDs of the nested master page. A web form cannot reach the ContentPlaceHolders in the master page above its own master page.

Content1

Content2

Content3

Master Pages and Configuration

There are three ways to associate a web form with a master page. You can use the Master attribute in the @ Page directive, and you can write to the MasterPageFile property in the PreInit event or earlier. Weve seen examples of both of these techniques. Any web form using the Master attribute of the @ Page directive or setting the MasterPageFile property programmatically will override the web.config settings.

We can also assign a default master page for all web forms in a site in our web.config file using the element. An example excerpt from web.config is shown below.

Of Headers and Meta tags

The last topic we will address is the topic of header information for ASP.NET web forms using a master page. The master page must define , meaning the master page will include the tag, among others. Since the master page does not know the title of the content page that will plug in, it simply sets the title to untitled.

Since a content page cannot contain any markup outside of Content controls, there is no way for a content page to use a title tag, but there is now a Title attribute in the @ Page directive. There is also a Title property on the page itself.

For other elements that end up in the header, the Page class now exposes a Header property of type HtmlHead. You can use the HtmlHead reference to modify style sheet settings and add HtmlMeta objects as needed.

Conclusions

Master pages provide a key component to any web application, namely the ability to organize a consistent layout into reusable templates. These master page templates offer full designer support and programmatic interfaces to meet the demands of most applications.