ASP.NET 3.5 CMS: Master Pages, Themes, and Menus

Cart | Your Account | Trade | Sitemap

Want to know more about Packt's Article Network? Interested in contributing your article ideas?

Please visit our FAQ for more information.

In this article by Jeff Cochran, we will be discussing about how to add security and membership to a Content Management system. we will divide this article in two parts. In this first part, we will cover configuring and using forms authentication, along with how to create the membership database and the login page.

In this article by Curt Christianson, we will discuss a number of visual aspects of a site design. Many of these topics are not specific to a CMS, but are great concepts to remember for any site you may be designing.

In this article, you will learn about implementing and using:

Master Pages
Themes
Menus and navigation

Master Pages

Earlier you were introduced to a feature called Master Pages, but what exactly are they? The idea behind them is the one that's been around since the early days of development. The idea that you can inherit the layout of one page for use in another is the one that has kept many developers scrambling with Includes and User Controls. This is where Master Pages come into play. They allow you to lay out a page once and use it over and over. By doing this, you can save yourself countless hours of time, as well as being able to maintain the look and feel of your site from a single place. By implementing a Master Page and using ContentPlaceHolders, your page is able to keep its continuity throughout.

You'll see on the Master Page (SimpleCMS.master) that it looks similar to a standard .aspx page from ASP.NET, but with some slight differences. The <@...> declaration has had the page identifier changed for a Master declaration. Here is a standard web page declaration:

<%@ Page Language="VB" MasterPageFile="~/SimpleCMS.master"
AutoEventWireup="false" CodeFile="Default.aspx.vb"
Inherits="_Default" Title="Untitled Page" %>

Here is the declaration for a Master Page:

<%@ Master Language="VB" CodeFile="SimpleCMS.master.vb"
Inherits="SimpleCMS" %>

This tells the underlying ASP.NET framework how to handle this special page. If you look at the code for the page, you will also see that it inherits from System.Web.UI.MasterPage instead of the standard System.Web.UI.Page. They function similarly but, as we will cover in more detail later, they have a few distinct differences.

Now, back to the Master Page. Let's take a closer look at the two existing ContentPlaceHolders. The first one you see on the page is the one with the ID of "Head". This is a default item that is added automatically to a new Master Page and its location is also standard. The system is setting up your page so that any "child" page later on will be able to put things such as Javascript and style tags into this location. It's within the HTML <head> tag, and is handled by the client's browser specially. The control's tag contains a minimal amount of properties-in reality only four, along with a basic set of events you can tie to. The reason for this is actually pretty straightforward - it doesn't need anything more. The ContentPlaceHolder controls aren't really meant to do much, from a programming standpoint. They are meant to be placeholders where other code is injected, from the child pages, and this injected code is where all the "real work" is meant to take place. With that in mind, the system acts more as a pass-through to allow the ContentPlaceHolders to have as little impact on the rest of the site as possible.

Now, back to the existing page, you will see the second preloaded ContentPlaceHolder (ContentPlaceHolder1). Again, this one will be automatically added to the new Master Page when it's initially added. Its position is really more of just being "thrown on the page" when you start out. The idea is that you will position this one, as well as any others you add to the page, in such a way as to complement the design of your site. You will typically have one for every zone or region of your layout, to allow you to update the contents within. For simplicity sake, we'll keep with the one zone approach to the site, and will only use the two existing preloaded ContentPlaceHolders for now at least.

The positioning of ContentPlaceHolder1 in the current layout is one where it encapsulates the main "body" for the site. All the child pages will render their content up into this section. With that, you will notice the fact that the areas outside this control are really important to the way the site will not only look but also act. Setting up your site headers (images, menus, and so on) will be of the utmost importance. Also, things such as footers, borders, and all the other pieces you will interact with on each page are typically laid out on your Master Page. In the existing example, you will also see the LoginStatus1 control placed directly on the Master Page. This is a great way to share that control and any code/events you may have tied to it, on every page, without having to duplicate your code.

There are a few things to keep in mind when putting things together on your Master Page. The biggest of which is that your child/content page will inherit aspects of your Master Page. Styles, attributes, and layout are just a few of the pieces you need to keep in mind. Think of the end resulting page as more of a merger of the Master Page and child/content page. With that in mind, you can begin to understand that when you add something such as a width to the Master Page, which would be consumed by the children, the Child Page will be bound by that.

For example, when many people set up their Master Page, they will often use a <table> as their defining container. This is a great way to do this and, in fact, is exactly what's done in the example we are working with. Look at the HTML for the Master Page. You will see that the whole page, in essence, is wrapped in a <table> tag and the ContentPlaceHolder is within a <td>. If you were to happen to apply a style attribute to that table and set its width, the children that fill the ContentPlaceHolder are going to be restricted to working within the confines of that predetermined size. This is not necessarily a bad thing. It will make it easier to work with the child pages in that you don't have to worry about defining their sizes-it's already done for you, and at the same time, it lets you handle all the children from this one location. It can also restrict you for those exact same reasons. You may want a more dynamic approach, and hard setting these attributes on the Master Page may not be what you are after. These are factors you need to think about before you get too far into the designing of your site.

Now that you've got a basic understanding of what Master Pages are and how they can function on a simple scale, let's take a look at the way they are used from the child/content page. Look at the Default.aspx (HTML view). You will notice that this page looks distinctly different from a standard (with no Master Page) page. Here you have what a page looks like when you first add it, with no Master Page:

<%@ Page Language="VB" AutoEventWireup="false"
CodeFile="Default2.aspx.vb" Inherits="Default2" %>
<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
     <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    </div>
    </form>
</body>
</html>

Compare this to a new Web Form when you select a Master Page.

<%@ Page Language="VB" MasterPageFile="~/SimpleCMS.master"
    AutoEventWireup="false" CodeFile="Default2.aspx.vb"
    Inherits="Default2" title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="head"
    Runat="Server">
</asp:Content>
<asp:Content ID="Content2"
    ContentPlaceHolderID="ContentPlaceHolder1"
    Runat="Server">
</asp:Content>

You will see right away that all the common HTML tags are missing from the page with a Master Page selected. That's because all of these common pieces are being handled in the Master Page and will be rendered from the Master Page. You will also notice that the page with a Master Page also has an additional default attribute added to its page declaration. The title attribute is added so that, when merged and rendered with the Master Page, the page will get the proper title displayed. In addition to the declaration tag differences and the lack of the common HTML tags being absent, the two ContentPlaceHolder tags we defined on the Master Page are automatically referenced through the use of a Content control. These Content controls tie directly to the ContentPlaceHolder tags on the Master Page through the ContentPlaceHolderID attribute. This tells the system where to put the pieces when rendering. The basic idea is that anything between the opening and closing tags of the Content control will be rendered out to the page when being called from a browser.

Themes

Themes are an extension of another idea, like Master Pages, that has kept developers working long hours. How do you quickly change the look and feel of your site for different users or usages? This is where Themes come in. Themes can be thought of as a container where you store your style sheets, images, and anything else that you may want to interchange in the visual pieces of your site. Themes are folders where you put all of these pieces to group them together. While one user may be visiting your site and seeing it one way, another user can be viewing the exact same site, but get a completely different experience.

Let's start off by enabling our site to include the use of Themes. To do this, right-click on the project in the Solutions Explorer, select Add ASP.NET Folder, and then choose Theme from the submenu:

The folder will default to Theme1 as its name. I'd suggest that you name this something friendlier though. For now, we will call the Theme as "SimpleCMSTheme". However, later on you may want to add another Theme and give your folders descriptive names, which will really help you keep your work organized.

You will see that a Theme is really nothing more than a folder for organizing all the pieces. Let's take a look at what options are available to us. Right-click on the SimpleCMSTheme folder we just created, select Add New Item, and you should see a list similar to this one:

Your items may vary depending on your installation, but the key items here are Skin File and Style Sheet. You may already be familiar with stylesheets if you've done any web design work, but let's do a little refresher just in case. Stylesheets, among other uses, are a way to organize all the attributes for your HTML tags. This is really the key feature of stylesheets. You will often see them referenced and called CSS, which stands for Cascading Style Sheets that I'll explain in more detail shortly, but it's also the file extension used when adding a stylesheet to your application. Let's go ahead and add Style Sheet to our site just like the example above. For our example, we'll use the default name StyleSheet.css that the system selects. The system will preload your new stylesheet with one element-the body{} element. Let's go ahead and add a simple attribute to this element. Put your cursor between the open "{" and close "}" brackets and press Ctrl+space and you should get the IntelliSense menu. This is a list of the attributes that the system acknowledges for addition to your element tag. For our testing, let's select the background-color attribute and give it a value of Blue. It should look like this when you are completed:

body {
background-color: Blue;
}

Go ahead, save your stylesheet, run the site, and see what happens. If you didn't notice any difference, that's because even though we've now created a Theme for the site and added an attribute to the body element, we've never actually told the site to use this new Theme. Open your web.config and find the <pages…> element. It should be located in the <configuration><system.web> section, as shown next:

Go ahead, select the <pages> element, and put your cursor right after the "s". Press the spacebar and the IntelliSense menu should show up like this:

You will see a long list of available items, but the item we are interested in for now is the theme. Select this and you will be prompted to enter a value. Put in the name of the Theme we created earlier.

<pages theme="SimpleCMSTheme">

We've now assigned this Theme to our site with one simple line of text. Save your changes and let's run the site again and see what happens. The body element we added to our stylesheet is now read by the system and applied appropriately. View the source on your page and look at how this code was applied. The following line is now part of your rendered code:

<link href="App_Themes/SimpleCMSTheme/StyleSheet.css"
   type="text/css" rel="stylesheet" />

Now that we've seen how to apply a Theme and how to use a stylesheet within it, let's look at one of the other key features of the Theme, the Skin file. A Skin file can be thought of as pre-setting a set of parameters for your controls in your site. This will let you configure multiple attributes, in order to give a certain look and feel to a control so that you can quickly reuse it at any time. Let's jump right in and take a look at how it works, to give you a better understanding. Right-click on the SimpleCMSTheme folder we created and select the Skin File option. Go ahead and use the defaulted name of SkinFile.skin for this example. You should get an example like this:

<%--
Default skin template. The following skins are provided as examples only.
1. Named control skin. The SkinId should be uniquely defined because
duplicate SkinId's per control type are not allowed in the same theme.
<asp:GridView runat="server" SkinId="gridviewSkin" BackColor="White" >
    <AlternatingRowStyle BackColor="Blue" />
</asp:GridView>
2. Default skin. The SkinId is not defined. Only one default
control skin per control type is allowed in the same theme.
<asp:Image runat="server" ImageUrl="~/images/image1.jpg" />
--%>

We now have the default Skin file for our site. Microsoft even provided a great sample here for us. What you see in the example could be translated to say that any GridView added to the site, with either no SkinID specified or with a SkinID of gridviewSkin, will use this skin. In doing so, these GridViews will all use a BackColor of White and AlternatingRowsStyle BackColor of Blue. By putting this in a Skin file as part of our Theme, we could apply these attributes, along with many others, to all like controls at one time. This can really save you a lot of development time. As we go through designing the rest of the CMS site, we will continue to revisit these Theme principles and expand the contents of them, so it is good to keep their functionality in mind as we go along.

Build, Manage, and Extend your own Content Management System
Create your own Content Management System with the understanding needed to expand it and add new functionality as your needs grow
Learn to build a fully functional application with very little code and set up users and groups within your application
Manage the layout of your site using Master Pages, Content Placeholders, Themes, Regions, and Zones
A step-by-step guide with plenty of code snippets and screen images

http://www.packtpub.com/asp-net-3-5-cms-development/book

Menus

Navigation is the heart of any web site. It's your direct interface to your customers and allows you to guide them to all of the content that you've spent hours on putting together. A poorly laid out navigation menu can destroy the usability of your site, and can also transform your site into one that your customers/users will enjoy using. There are two common ways that menus are done within most ASP.NET web sites. The first is what I would consider the "old" way of doing it. That would be the manual method of making menus. By using simple HTML <a href..> tags, you could easily place a series of links on your page and, in reality, you have a menu. This will work great in certain circumstances. If your site has a very limited number of items you wish to display on the menu, if your menu is something that is likely to seldom change, and if you don't really have the need to dynamically enable or hide your menu items, then you may find that this simple menu system is one that will fit your needs nicely. It's still a commonly used option and is very fast and easy to set up. It could be as simple as the following code:

<td>
  <a href="Somepage1.aspx" title="Some Page 1">Click Me</a>
  <a href="Somepage2.aspx" title="Some Page 2">Click Me</a>
  <a href="Somepage3.aspx" title="Some Page 3">Click Me</a>
  <a href="Somepage4.aspx" title="Some Page 4">Click Me</a>
  <a href="Somepage5.aspx" title="Some Page 5">Click Me</a>
</td>

With the above approach, you really could do a lot more than just this simple list of links, but it would involve doing a great deal of CSS and Javascript, not to mention really involving a time commitment to develop and lots of potential cross-browser issues. This is where the ASP.NET tools can really come into play and save you a great deal of time. Microsoft has taken most of the things you may want to do with your series of links, and done the work for you. Visual effects, drop-down sub-menus, and permissions are just a few of these pre-designed features. For this example, let's go ahead and put a Menu control on our Master Page. Open up the SimpleCMS.master page in the designer and drag a Menu control from the toolbox on to our page right below our logo.

As you can see, it has a set of default values; but for our needs, let's go ahead and replace these right away, and make this a horizontal menu instead of a vertical (the default) one. Doing this is as simple as going to the Menu Properties, looking in the Layout section, and changing its Orientation.

Another quick and easy thing we can do is change the look and feel of the menu. We could tweak all the little settings on the menu or we could take advantage of a number of pre-built themes that Microsoft has provided for us. Click the Menu Tasks button to extend them.

Then select the AutoFormat option.

Here you will see a list of four pre-built options, as well as a handy option, to remove all the formatting. These formats are made to be used not only as they are, but also as a great starting point for your own design. Let's choose the Simple option for our site. If you were to run the site right now, you would notice that our menu doesn't show up. This is not because we've done anything incorrectly; it's because even though we've added a menu to the site, we haven't yet added any items to the menu. For this, you again have two common ways of doing it. The first, again, is the more straightforward and simplistic approach. We can simply click the Menu Tasks button and choose Edit Menu Items. You will see an empty editor screen.

From here, simply choose Add Root Item.

Then go ahead and give it some Text and a Value. Click Save and run your site once. You will see that the following screen will show up:

We really don't want a menu with just one item on it, so let's stop the site and go back in to the menu editor. Go ahead and add three more Root menu Items to your menu. When you are done with that, select your third Root menu item and choose the Add Child Menu Item from the editor.

Add a couple of child items to your third Root menu Item. Be sure that you always highlight the Root menu item when you choose the Add Child, or you may find yourself adding child items in places you didn't intend them to be. When you are done, you should have a menu that looks something like this:

Go ahead and click the OK button and then run your site. You will see that it will display your new menu, as shown in the following figure:

Now as you can see, this would work perfectly well and you could easily create your menu items like this, but there is another way. If you still have the site running, go ahead and stop it. In your Solutions Explorer, select the root of your site. Then, from the menu, choose File | New File. Choose the Site Map option from the list.

As always, you could leave the name of the file to the defaulted name, but in this case, we will use the defaulted name of web.sitemap. By keeping the default name, it will save us some configuration work later. It will create a set of default entries and take us immediately into the editor when we click OK.

<?xml version="1.0" encoding="utf-8" ?>
<siteMap
xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
  <siteMapNode url="" title="">
          <siteMapNode url="" title="" description="" />
          <siteMapNode url="" title="" description="" />
  </siteMapNode>
</sitemap>

As you can see, the site map is really nothing more than an XML file with some special tag names. Let's go ahead and create some simple entries in our file so that the end result looks something like this:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap
xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
  <siteMapNode url="" title="">
          <siteMapNode url="~/Default.aspx" title="Link 1"
description="Link 1" />
          <siteMapNode url="~/Default.aspx" title="Link 2"
description="Link 2" />
          <siteMapNode url="~/Default.aspx" title="Link 3"
description="Link 3" />
          <siteMapNode url="~/Default.aspx" title="Link 4"
description="Link 4" />
  </siteMapNode>
</sitemap>

Now, let's go back to the Menu control we added to our Master Page. From that menu, choose the Tasks button, and then select Choose Data Source.

Select New Data Source from the menu and you will get a screen like this.

Click OK and you will now see that our page has a new control placed on it. This new SiteMapDataSource1 control has been automatically created for us.

If you were to run the site right now, you would see that the menu we added is now populated, but odds are that it's not quite laid out as you would have expected. Stop the running of the site and let's go to the properties on the SiteMapDataSource.

Our current sitemap file contains a "root" tag. This is simply the container that must exist to group all the other menu items together. However, in this case, we don't want that to actually show on the page, so we will set the ShowStartingNode property to False. This will tell the menu control to skip that first item and display the next level of items as the root of the menu. Run the site again and you should see a much different look for the menu on the site.

From here out, anytime you want to add a menu item, it's simply a matter of editing the web.sitemap file and instantly that menu change will be displayed throughout the site.

Summary

In this article, we covered the concepts of why you lay out your site in a particular way, as well as beginning to help you understand all the pieces involved in this process. All of these pieces - Master Pages, Themes, CSS, Skins, Sitemaps, and Menus-combine together to make your site work. A solid understanding of these pieces will help you as you put together all the individual components. However, more importantly, it will aid you as you continue to expand your site, giving you the ability to quickly update it with as little work as possible.

If you have read this article you may be interested to view :

Build, Manage, and Extend your own Content Management System
Create your own Content Management System with the understanding needed to expand it and add new functionality as your needs grow
Learn to build a fully functional application with very little code and set up users and groups within your application
Manage the layout of your site using Master Pages, Content Placeholders, Themes, Regions, and Zones
A step-by-step guide with plenty of code snippets and screen images

http://www.packtpub.com/asp-net-3-5-cms-development/book

About the Author

Curt Christianson has been involved in the tech community since the mid 1990's and has been a professional developer for more than a decade. He is an active community contributor on the ASP.NET forums, as well as a Forum Moderator. He has won six Microsoft Most Valuable Professional (MVP) awards for his work with ASP/ASP.NET. He is writing a number of open source add-ins and starter kits. He is based in Wisconsin, U.S.A. as a professional developer, as well as contributing to books and articles, both printed and on the Internet.

Choosing an Open Source CMS: Beginner's Guide

Drupal 5 Views Recipes

JBoss Tools 3 Developers Guide

WordPress 2.7 Cookbook

Plone 3 Theming

Drupal 6 Content Administration

Apache Struts 2 Web Application Development

Alfresco 3 Enterprise Content Management Implementation

Visit Packt's Article Network, for all the latest quality, relevant and free content.
See More

In this two-part article by Jeff Cochran, we will be discussing about how to add security and membership to a Content Management system. In the first part we saw how to create Forms authentication and how to use it, along with how to create home page, Master Page, and login page. In this part of the article will focus on adding Forms authentication to our CMS, along with creating user accounts and how to assign membership roles.