Are master files a replacement for user controls for overall layout?

[Alan Silver]

Hello,

In classic ASP, I used to use two include files on each page, one before
and one after the main content, to provide a consistent layout across a
web site. That way I could just change the include files to change the
layout. When I came to ASP.NET, I used user controls to do a similar
thing.

I have just been looking at master pages, and it looks like they do the
same thing. If so, is there any advantage in using them over the user
controls? Obviously master pages allow you to have one file instead of
two, but that's not a huge advantage. I'm wondering if there's more to
them than I have seen so far.

Thanks for any info.

 

[woutervu]

Some of the things I can think of:
-You can create more dynamic layouts, using designer support
-Performance improvements, the ASP.NET runtime knows about MasterPages
-Configurable from web.config

I believe MasterPages came forth of a project using special controls &
designers, so I think the runtime support is the major factor here..

 

[Alan Silver]

Some of the things I can think of:

Thanks for the reply, but I'm not really clearer;-(

-You can create more dynamic layouts, using designer support

More dynamic in what way? Do you mean you can change them at run time?
If so, why can't you do this with user controls?

-Performance improvements, the ASP.NET runtime knows about MasterPages

The runtime knows about user controls too. Are you saying that using
master pages gives better performance than having a user control with
some HTML and/or server tags in? I'm not saying you're wrong, but I find
it hard to believe as you are adding an extra layer of complexity with
master pages.

-Configurable from web.config

Please explain what you mean and why this would be useful.

I believe MasterPages came forth of a project using special controls &
designers, so I think the runtime support is the major factor here..

Thanks for the reply, but I would appreciate some more info here as I
don't really see what you mean.

 

[Scott Allen]

Hi Alan:

With master pages you'll never have to "include" a common header and
footer. You tell the master page where the header and footer go and
then your content pages just plugin the content.

Your header and footer might still be implemented inside of two user
control files - but you'll never have to layout those two user
controls on every content page - just on the master page(s) in your
app.

Make more sense?

 

[Alan Silver]

Hi Scott,

Thanks for the info. It does make sense, but I'm still not sure if I'm
missing something here. The way you describe it (which is the way I
understood it), master pages aren't much of an improvement over using
two user controls. Spot the difference between the next two
paragraphs...

1) Using the user controls, every page "includes" two controls. Changing
the layout of the site involves changing one or both of these controls,
and all pages see the changes.

2) Using master pages, every page refers to one master. Changing the
layout of the site involves changing the one master file, and all pages
see the changes.

Very similar eh? Apart from the minimal advantage of having the common
code in one file instead of two, it doesn't seem anything worth jumping
in the air and going "whoopee" about!!

That's why I feel I'm missing something. There must be some bigger
advantage to master pages, no? From what I understand so far, there's
certainly no incentive to go and change existing sites to use master
pages. New sites will probably use them as they do have the slight
advantage of one file over two, but the convenience isn't worth the
effort of changing an existing site.

Thanks for the reply. Any further comments welcome.

 

[Scott Allen]

Very similar eh? Apart from the minimal advantage of having the common
code in one file instead of two, it doesn't seem anything worth jumping
in the air and going "whoopee" about!!

It is similar. Here are some advantages I can think of quickly:

1) You want to change the layout for the entire site by, say, changing
the position of the two user controls. Without master pages you'd have
to go to every aspx form with those two controls and make the
modification. With master pages you only need to make one change.

2) You can have multiple master pages for a site and easily switch
between master pages programatically, say, based on a user's
preference.

 

[Alan Silver]

Very similar eh? Apart from the minimal advantage of having the common

It is similar. Here are some advantages I can think of quickly:

1) You want to change the layout for the entire site by, say, changing
the position of the two user controls. Without master pages you'd have
to go to every aspx form with those two controls and make the
modification. With master pages you only need to make one change.

I suppose it depends how you set up the user controls. The way I do it
(which is directly inherited from the way I did include files in Classic
ASP) wouldn't really give rise to this problem.

The fact of only having one file to change is definitely an advantage,
just not necessarily a big enough one to justify modifying existing
pages.

2) You can have multiple master pages for a site and easily switch
between master pages programatically, say, based on a user's
preference.

Well, you can do the same with the user controls. You just have to
change two files instead of one.

Which brings me to another point I was pondering. Is there a sensible
way to select master pages programmatically, without incurring a
performance hit? For example, suppose I have a site with three master
pages, a normal one, one for Nov-Dec and one for (say) the summer
season. I would like to be able to add a feature to the site owner's
admin pages so they can choose the theme (ie master page). I guess I
could do this by setting an application variable with the name of the
current theme, but isn't that going to incur a (small) performance hit
every time a page is loaded? For something that will only change a few
times a year, this seems a poor trade off. Is there a more efficient way
of doing it?

Thanks for the info.

 

[Scott Allen]

Well, you can do the same with the user controls. You just have to
change two files instead of one.

Yes, to some extent. You can do most of master pages using just CSS
and relative positioning, too. I think it's important to distinguish
between the two as:

- user controls encapsulate a specific piece of functionality (i.e.
a page footer)

- master pages encapsualte layout (the footer is always wrapped in a
<div> at the bottom of a page).

In any case, if you already have something that works for you than no
reason to change.

Which brings me to another point I was pondering. Is there a sensible
way to select master pages programmatically, without incurring a
performance hit? For example, suppose I have a site with three master
pages, a normal one, one for Nov-Dec and one for (say) the summer
season. I would like to be able to add a feature to the site owner's
admin pages so they can choose the theme (ie master page).

I think for that scenario I'd use <pages master="fall.master" /> in
web.config. The WebConfigurationManager class allows writing to
web.config now, so you could write the new setting from an admin page.

 

[Alan Silver]

Well, you can do the same with the user controls. You just have to

Yes, to some extent. You can do most of master pages using just CSS
and relative positioning, too. I think it's important to distinguish
between the two as:

- user controls encapsulate a specific piece of functionality (i.e.
a page footer)

- master pages encapsualte layout (the footer is always wrapped in a
<div> at the bottom of a page).

That's a very good way of looking at it. Seen like that, user controls
aren't really the ideal way to do it. Sure they work, but the master
page approach is more logical.

In any case, if you already have something that works for you than no
reason to change.

No, but for new sites it's worth knowing what the best practice is.

I think for that scenario I'd use <pages master="fall.master" /> in
web.config. The WebConfigurationManager class allows writing to
web.config now, so you could write the new setting from an admin page.

Yeah I saw that yesterday. Doesn't it mean that *every* page on the site
has to use that master page though? That might not always be the best
thing. Can individual pages override the web.config setting?

Thanks again for the help and advice.

 

[Scott Allen]

Yeah I saw that yesterday. Doesn't it mean that *every* page on the site
has to use that master page though? That might not always be the best
thing. Can individual pages override the web.config setting?

Yes, if a page uses use MasterPageFile attribute or set's the
MasterPageFile property before the Init event it will override what
the web.config file says...

 

[Alan Silver]

Yeah I saw that yesterday. Doesn't it mean that *every* page on the site

Yes, if a page uses use MasterPageFile attribute or set's the
MasterPageFile property before the Init event it will override what
the web.config file says...

Ooh, that's good. What if I want a page not to use a master page at all?
Say I have (common scenario) all pages in the site using a common layout
(which would be in the one master file), but the home page has a
different layout. In this case, it would be a waste to produce a master
page just for the home page, you might as well just have the layout
directly in the .aspx file. Can I tell the home page not to use a master
at all?

Thanks for the info.

 

[Juan T. Llibre]

re:

Can I tell the home page not to use a master at all?

Just don't include the MasterPageFile="~/YourMasterPage.master"
in your Page directives.

Using <%@ Page Language="VB|C#" %>
won't include the MasterPage in that aspx file.

I *never* use web.config to set a MasterPage.

I only use <%@ Page Language="VB|C#" MasterPageFile="~/My.master"%>
in the pages in which I want to have my Master layout inherited.

 

[Scott Allen]

Ooh, that's good. What if I want a page not to use a master page at all?
Say I have (common scenario) all pages in the site using a common layout
(which would be in the one master file), but the home page has a
different layout. In this case, it would be a waste to produce a master
page just for the home page, you might as well just have the layout
directly in the .aspx file. Can I tell the home page not to use a master
at all?

I can't test it at the moment, but I suspect if you set the
MasterPageFile attribute / property for the aspx page to null (or
perhaps an empty string?), then it wouldn't use a master. I'll try
that out later this evening...

 

[Alan Silver]

Can I tell the home page not to use a master at all?

Just don't include the MasterPageFile="~/YourMasterPage.master" in your
Page directives.

Using <%@ Page Language="VB|C#" %>
won't include the MasterPage in that aspx file.

I *never* use web.config to set a MasterPage.

I only use <%@ Page Language="VB|C#" MasterPageFile="~/My.master"%> in
the pages in which I want to have my Master layout inherited.

Yeah, but the point of my question was to find an easy way of changing
the master page for a whole site, without having to edit every page
individually. The idea of using web.config to specify the master page
works a treat as I can just change the one entry, and have the whole
site use a different master page. I was just trying to find out if I was
forced to have every page using the master page (which is the
implication I got from the info I read yesterday), or if I could have a
page without any master page at all.

Thanks for the reply.

 

[Alan Silver]

web.config. The WebConfigurationManager class allows writing to
web.config now, so you could write the new setting from an admin page.

I just tried this and it gave me an error, saying the attribute "master"
is not recognised. I am using VWD beta 2, and .NET framework version
2.0.50215

I have searched the docs, and looked in the config files on my hard
disk, but can't find any reference to an entry for "master".

Here is the web.config...

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<appSettings>
</appSettings>
<connectionStrings/>
<system.web>
<pages master="MasterPage.master" />
<compilation debug="true"/>
<authentication mode="Windows"/>
</system.web>
</configuration>

 

[Alan Silver]

I just tried this and it gave me an error, saying the attribute

"master" is not recognised

OK, I finally found it. The attribute is masterPageFile, not master. The
correct syntax is...

<system.web>
<pages masterPageFile="~/MasterPage2.master" />
</system.web>

I also discovered that you can have a normal .aspx page in the same web
site and it just ignores the above setting. It seems this is only used
with a page that has a Content control.

However, when I ran a page like this, I got errors from VWD. It compiled
and displayed the page fine, but it complained that the element "html"
occurs too few times (zero actually, as a page that uses a master
shouldn't have this tag), that "asp" is an unrecognised tag prefix or
device filter, and that the element "p" must be included within a parent
element.

All of these errors seem to come from the fact that the .aspx didn't
have a full HTML like a normal page, it only had the Content control.
Surely VWD should know about this. Any ideas why I got the errors?

Ta ra

 

[Juan T. Llibre]

re:

site use a different master page. I was just trying to find out if I was forced to have
every page using the master page (which is the implication I got from the info I read
yesterday), or if I could have a page without any master page at all.

You can have a page without any master page at all, by simply including
an empty string as the MasterPageFile directive, as Scott surmised :

<%@ Page MasterPageFile="" %>

You will have to build all the HTML you need on that page though,
which I think is what you want to do, anyway.

You could, also, if you need several templates, determine
a *different* MasterPageFile than the one specified in web.config :

<script language="c#" runat="server">
protected override void OnPreInit(EventArgs e)
{
this.MasterPageFile = "another.master";
base.OnPreInit(e);
}
</script>

best,

 

[Scott Allen]

I'm using the RTM version and the syntax (both now and in beta 2 if I
remember correctly) is:

<pages masterPageFile="fall.master">

Apologies if I didn't specify the correct attribute.

You might also want to fully qualify the path, i.e:

<pages masterPageFile="~\fall.master">

 

[Alan Silver]

You can have a page without any master page at all, by simply including

an empty string as the MasterPageFile directive, as Scott surmised :

<%@ Page MasterPageFile="" %>

You will have to build all the HTML you need on that page though, which
I think is what you want to do, anyway.

I discovered that you can just have a normal aspx without any reference
to a master page and it will work fine. The way I read the docs
yesterday was that *all* pages in the site were forced to use the master
page specified in web.config. It seems that this isn't right, it's only
the pages that have a Content control, and that don't override the
masterPageFile attribute themselves.

So, it all looks exactly like I want, except for the errors I mentioned
in my other post. If you can shed any light on those I would be
grateful.

Ta ra

 

[Juan T. Llibre]

re:

However, when I ran a page like this, I got errors from VWD. It compiled and displayed
the page fine, but it complained that the element "html" occurs too few times (zero
actually, as a page that uses a master shouldn't have this tag), that "asp" is an
unrecognised tag prefix or device filter, and that the element "p" must be included
within a parent element.

All of these errors seem to come from the fact that the .aspx didn't have a full HTML
like a normal page, it only had the Content control. Surely VWD should know about this.
Any ideas why I got the errors?

Because you don't have properly formed HTML.

If you use the "empty string" MasterPageFile directive, as I explained in my
previous post, and you build your HTML for the aspx file in *that* page
( since there's no MasterPageFile and there isn't *any* HTML coming from
a MasterPageFile ), you'll be fine.

i.e., :

<%@ page Language="VB|C#" MasterPageFile="" %>

<html>
<head>
<title>
No master page.
</title>
</head>
<body>
Place whatever you want as content here.
If you want scripting power, use code behind, or use a
<Script language="language" runat= "server">
functions...
</script>
section below the Page directive line.
</body>
</html>