Accessing Master Page Controls from Content Pages Although Master Pages provide the common content for all the pages, sometimes you may need to access master page controls from within content pages and modify their values. To access the master page controls from a content page, invoke the Page.Master property, which returns a reference to the master page. Using that reference, you have direct access to the controls in the master page. This is a very powerful feature that gives content pages complete control over the content rendered through the master pages. There are two ways you can access the controls available in the master page.
- In the first approach, you expose the controls in the master page using public properties. This means you need to create one property for each control that should be made available to the content pages.
- In the second approach, you get a reference to the master page controls in a standard way?using the FindControl method?which is available because the Master class derives from System.Web.UI.Page class.
The following code shows an example that accesses a control in the master page from a content page.
Master Page
The preceding code is very similar to the code in Listing 1; however this version contains a server side control named “Header” in the header section. The following code shows how to access the Header control from a content page.
This content is generated from the content page.
The preceding code starts by specifying the name of the master file to use. The Page_Load event?invokes the FindControl method of the Master class, passing it the name of the master page control to find. The code casts the returned value to a Label control and then sets its Text value.
Apart from accessing all the controls of the master page, you can also access the public properties and methods exposed by the master page from the content pages using an early-bound approach. This early-bound approach not only increases the performance but also provides compile time type-checking, resulting in increased developer productivity.
Nesting Master Pages There are times where you may want to provide overall branding and appearance for your Web site, but at the same time provide sub-sites whose appearance must be consistent. To accomplish this, you need to nest one master page within another page, a process called “Nesting Master Pages”. Nesting support is built-in, which means you don’t have to do anything special to reap the advantages of nested master pages; a content page that uses a sub-master page will automatically receive content from all the master pages in the hierarchy.
Consider the MSDN Web site as an example to understand how you can use the nested master page architecture to provide a consistent look and feel. As you probably know, MSDN is the home for several developer centers that cover the .NET framework, ASP.NET, Visual Studio, Security, Web services, and Windows Server 2003, among others. Using the master pages architecture, you could implement a consistent look and feel across all the developer centers. For example, you can have the main MSDN page derive from a root master page. Each developer center can have its own master page, each of which uses the root master page as its master. This means a content page in any of the developer centers will inherit the root master page look and feel settings that provide overall MSDN branding, and will also inherit the custom look and feel specific to that developer center. This nested approach?provides each developer center with the freedom to develop customized content while maintaining a consistent overall branding for the entire site. The downloadable code for this article provides an example of nested master pages.
Configuring Master Pages So far, you’ve used the master attribute of the Page directive in the content pages to specify the name of the master page. Even though this approach works, it requires you or your developers to specify the master attribute in each page. You can eliminate that requirement by specifying the name of the master file in the web.config file under the pages element. After adding the entry to your web.config file, all the pages in that Web application will automatically use the designated master page. For example, the following web.config file entry specifies that all the pages in the Web application should use IntroMaster.master as their default master page.
You’re not limited by setting the default master page in the web.config file. Even when you use this method to specify the name of a default master page, you can still override the global value by specifying a different master page in the master attribute of the Page directive. Any values you specify using the Page directive takes precedence over the web.config file entry.
To sum up, ASP.NET’s new Master Pages feature provides a clean approach to encapsulate common functionality and content a centralized location, allowing other pages to inherit from those master pages, thereby greatly reducing the maintenance. Using master pages, you can also create one set of controls and code and apply the results to all your content pages. Apart from providing a fine-grained control over the layout of the content pages, master pages also expose an object model that allows you to access the master page controls, properties and methods from content pages.
|