A brief history of MasterPages and templating web content (aka MasterPages are NOT frames)

發行項
04/05/2006

One question I see constantly on the forums is: How do I get a Masterpage to load Content1 from one page but Content2 from another page or How do I get Content2 to reload when I click a button in Content1 without reloading the entire page.

The root of the question is often a misunderstanding of the concept of a Masterpage and confusing it with frames. Masterpages are a way of templating a site. By this I mean defining a look and feel for the overall site and proving a central point for common code while allowing individual pages to modify their specific content. This is not the same thing as a frame although frames are sometimes used this way. Instead, frames are a way of collaging multiple arbitrary pages together in a single browser. Frames are also a bad idea [www.karlcore.com].

To begin with, I need to make the assumption that a consistent layout across various pages on a site is a good thing. I hope this can be agreed on. Secondly, duplication of code is a bad thing and hard to maintain. I also hope that this can be agreed on. The conclusion is that it would be good if the code that manages the look and feel of a site as well as the common components (such as a navigation system, header, and footer) was kept in as few and as specific as possible locations.

To explain the motivation for Masterpages and give a little more perspective on how they were designed, let me start with an older and little seen anymore concept that was used to solve this problem. It is called "Server Side Includes". SSI was a relatively light weight way that a server could merge together multiple files into a single output stream to the client. This was probably one of the first big steps into a web server actually parsing content (rather than just streaming it) and it looked something like this:

<td>This is some content data here
</td>

Those aren't just html comments, they are also directives that the web server understands. You can imagine that header.html and footer.html contained the html for a header and a footer. Somewhere in there depending on the layout of the page was likely to be a navigation menu and perhaps copyright info, etc. Well, this worked fine when it was 1998 but with new technology (like ASP) we wanted a bit more features. For one thing, it would be nice of the header/footer could interact with the content and vice-versa. So, the natural progression was to use UserControls like this:

<%@ Register Src="header.ascx" TagName="header" TagPrefix="uc1" %>
<%@ Register Src="footer.ascx" TagName="footer" TagPrefix="uc2" %>

<uc1:header ID="Header1" runat="server" />
    <form id="form1" runat="server">
    <div>
        Some Content Here
    </div>
    </form>
<uc2:footer ID="Footer1" runat="server" />

Again, header markup was in header.ascx and footer markup was in footer.ascx pretty much like before. Well, this was certainly much better than the SSIs we had before but there were still other nagging problems. One big one was that you were almost certain to have invalid XML/HTML code in the header/footer controls. For example, the <html> tag was likely to be opened in the header but closed in the footer leaving both files with dangling tags. The alternative was to bring a lot of layout code into the page which defeated the purpose of this whole arrangement.

So, with Masterpages, we can address these issues (note: while I've demonstrated a problem we've solved, I don't mean to convey that this is the only problem we've tried to solve, there are certainly many others). The Masterpage becomes the place where the layout of a site is created and where common components such as navigation can be placed. The content pages, are exactly that, pages which contain content that is specific to the page. And it looks something like this as most users are probably aware:

Master Page:

<%@ Master Language="VB" %>
<html xmlns="https://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <h1>This is my Header</h1>
    <form id="form1" runat="server">
        <div>
            <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
                
            </asp:ContentPlaceHolder>
        </div>
    </form>
    <h2>This is my Footer</h2>
</body>
</html>

Content Page:
<%@ Page Language="VB" MasterPageFile="~/MasterPage.master" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
This is some content
</asp:Content>

So, in summary, I hope that a reader who has made it this far will realize that Masterpages and content pages are not frames. Masterpages do not let you to mash many pages together in the browser. They better than that, they are a tool for designing a website with good design practices and well formatted markup.

Comments

Anonymous
April 28, 2006
You've made your point with the advantages of Masterpages versus templates as far as keeping your page consistency. I enjoyed playing with the masterpage/contentplaceholder feature but the reloading on the masterpage when the content changes is a big problem. How would you address this issue? Seems that eventhough the masterpage/contentholder feature offers a lot of wonderful advantages such as simplicity in code, better manageable design and layout. It seems that the reloading problem is far outweighing the good things about masterpages.
Anonymous
June 07, 2009
PingBack from http://greenteafatburner.info/story.php?id=5547

共用方式為

A brief history of MasterPages and templating web content (aka MasterPages are NOT frames)

Comments

其他資源