Master Pages in Asp.Net
Definition:
ASP.NET
master pages allow us to create a consistent layout for the pages in our
application. A single master page
defines the look and feel and standard behavior that we want for all of the
pages or a group of pages in our application. We can then create individual content pages
that contain the content we want to display. When we request the content pages, they merge
with the master page to produce output that combines the layout of the master
page with the content from the content page.
Working of Master Page:
Master
pages actually consists two pieces, one is the master page itself and other is one
or more content pages.
Master
Pages – A master page is an ASP.NET file with the extension .master (eg: Example.master) with a predefined layout that
can include static text, HTML elements, and server controls. The master page is identified by a special directive,
“@Master” that replaces the “@Page” directive that is used for ordinary .aspx pages. See the below how the directive looks like.
<%@ Master Language="C#" %>
The “@Master” directive can contain most of
the same directives that a “@Control” directive can contain. For
example, see the following master-page directive which includes the name of a
code-behind file, and assigns a class name to the master page.
<%@ Master Language="C#" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
In
addition to the “@Master” directive, the master page
also contains all of the top-level HTML elements for a page, such as html, head, and form. For
example, in a master page we might use an HTML table for the layout, an img element for our company logo,
static text for the copyright notice, and server controls to create standard
navigation for our site. We can use any
HTML and any ASP.NET elements as part of our master page.
Replaceable
Content Placeholders:
The master page also
includes one or more “ContentPlaceHolder” controls in addition to static text and
controls that will appear on all pages. These
placeholder controls define regions where the replaceable content will appear. In turn, the replaceable content is defined in
content pages. After we defined the ContentPlaceHolder controls, a master page might look like the
following.
<%@ Master Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML
1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server" >
<title>Master page title</title>
</head>
<body>
<form id="form1" 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>
Content
Pages:
We can define the content for
the master page's placeholder controls by creating individual content pages,
which are ASP.NET pages (.aspx files and, optionally, code-behind files) that
are bound to a specific master page. The
binding is established in the content page's @Page directive by including a “MasterPageFile” attribute which
points to the master page to be used.
For example, a content page
might have the following @Page directive,
which binds it to the Master1.master page.
<%@ Page Language="C#" MasterPageFile="~/MasterPages/Master1.master" Title="Content Page"%>
In the
content page, we can create the content by adding Content controls and mapping them to ContentPlaceHolder controls on the master page.
For
example, the master page might have content placeholders called Main and Footer. In the
content page, we can create two Content controls, one that is mapped to the ContentPlaceHolder control, “Main” and the other mapped to the ContentPlaceHolder control “Footer”, as shown in the following
figure.
For example, we can generate
content for a Content
control using server controls and database queries or other dynamic mechanisms.
See below for how the content
page might look like.
<% @ Page Language="C#" MasterPageFile="~/Master.master" Title="Content Page 1" %>
<asp:Content ID="Content1" ContentPlaceHolderID="Main" Runat="Server">
Main content.
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="Footer" Runat="Server" >
Footer content.
</asp:content>
The @Page directive binds the content page to a specific master page, and it
defines a title for the page that will be merged into the master page. Note that the content page contains no other
markup outside of the Content
controls. (The master page
must contain a “head” element with the attribute runat="server" so
that the title setting can be merged at run time.
Note: We can create multiple
master pages to define different layouts for different parts of our site, and a
different set of content pages for each master page.
Advantages:
·
They allow us to centralize the common functionality of our pages
so that we can make updates in just one place.
·
They make it easy to create one set of controls and code and apply
the results to a set of pages. For
example, we can use controls on the master page to create a menu that applies
to all pages.
·
They give us fine-grained control over the layout of the final
page by allowing us to control how the placeholder controls are rendered.
·
They provide an object model that allows us to customize the
master page from individual content pages.
Run-time Behavior of Master Pages:
At run time, master pages are
handled in the following sequence:
1. Users
request a page by typing the URL of the content page.
2. When
the page is fetched, the @Page directive
is read. If the directive references a
master page, the master page is read as well. If this is the first time the pages have been
requested, both pages are compiled.
3. The
master page with the updated content is merged into the control tree of the
content page.
4. The
content of individual Content
controls is merged into the corresponding ContentPlaceHolder
control in the master page.
5. The
resulting merged page is rendered to the browser.
Master Page and Content Page Paths:
When a content page is
requested, its content is merged with the master page, and the page runs in the
context of the content page.
For example, if you get the CurrentExecutionFilePath
property of the HttpRequest
object, whether in content page code or in master page code, the path
represents the location of the content page.
The master page and content page do not have
to be in the same folder. As long as the
MasterPageFile
attribute in the content page's @Page directive
resolves to a .master page, ASP.NET can merge the content and master pages into
a single rendered page.
Referencing
External Resources:
Both the content page and
master page can contain controls and elements that reference external
resources.
For example, both might
contain image controls that reference image files, or they might contain
anchors that reference other pages.
The context for the merged
content and master pages is that of the content page. This can affect how you specify URLs for
resources, such as image files and target pages, in anchors.
Server Controls:
In server controls on master
pages, ASP.NET dynamically modifies the URLs of properties that reference
external resources.
For example, we might put an Image
control on a master page and set its ImageUrl
property to be relative to the master page. At run time, ASP.NET will modify the URL so
that it resolves correctly in the context of the content page.
ASP.NET can modify URLs in the
following cases:
·
The URL is a property of an ASP.NET server control.
·
The property is marked internally in the control as being a URL.
(The property is marked with the attribute UrlPropertyAttribute.) In
practical terms, ASP.NET server control properties that are commonly used to
reference external resources are marked in this way.
Other Elements:
ASP.NET cannot modify URLs on
elements that are not server controls.
For example, if we use an img element on a master page and set its src attribute
to a URL, ASP.NET will not modify the URL. In that case, the URL will be resolved in the
context of the content page and create the URL accordingly.
In general, when working with
elements on master pages, it is recommended that we use a server control, even
for elements that do not require server code.
For example, instead of using
an img element, use an Image
server control. In that way, ASP.NET can
resolve URLs correctly and you can avoid maintenance issues that might arise if
we move the master or content page.
Master Pages and Themes:
We cannot directly apply an
ASP.NET theme to a master page. If we
add a theme attribute to the @Master directive,
the page will raise an error when it runs.
However, themes are applied to master
pages under these circumstances:
·
If a theme is defined in the content page. Master pages are resolved in the context of
content pages, so the content page's theme is applied to the master page as
well.
·
If the whole site is configured to use a theme by including a
theme definition in the pages
Element (ASP.NET Settings Schema) element.
Scoping Master Pages:
We can attach content pages to a master page at three levels:
At the page level: We can
use a page directive in each content page to bind it to a master page, as following.
<%@ Page Language="C#" MasterPageFile="Example.Master" %>
At the application level: By
making a setting in the pages element of the application's
configuration file (Web.config), we can specify that all ASP.NET pages (.aspx
files) in the application automatically bind to a master page, as following.
<pages masterPageFile="Example.Master" />
At the folder level: This
strategy is like binding at the application level, except that we make the
setting in a Web.config file in one folder only. The master-page bindings then
apply to the ASP.NET pages in that folder.
can i knw , how to include notepad,or word or calculator appliaction , without creating them , i mean how to use applications which are already present in system
ReplyDelete