Sharepoint Web Content Management

Overview

Many things ASP.NET 2.0 developers are used to building can seem challenging within a Microsoft Office SharePoint Server (MOSS) 2007 environment. However, because the MOSS 2007 architecture is based on ASP.NET 2.0, developers can now use nearly all the same techniques they implemented in ASP.NET 2.0 sites in SharePoint sites they develop. One of these techniques is to make use of code-behind files within master pages and page layouts that are used in MOSS 2007 Web content management (WCM) publishing sites.
Code It

First, create a class file (Microsoft Visual C# in this example) in a Class Library project that inherits from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class (or System.Web.UI.MasterPage if you are creating a code-behind file for a master page). You should name this class with the same name as the file, but it is not required.
C#

using System;
using System.Web.UI;
using Microsoft.SharePoint.Publishing;

namespace MSDN.SharePoint.Samples {
public class PageLayoutTemplate : PublishingLayoutPage {
}
}

Wiring the Code-Behind to the Master Page or Page Layout

Next, wire the code-behind file to the master page or page layout. This is done by entering the fully qualified name, otherwise known as the five-part name, in the Inherits attribute of the page layout or master page directive. The five-part name is the full type name (namespace.class) followed by the strong name of the signed assembly.
C#

<%@ Page meta:progid="SharePoint.WebPartPages.Document" Language="C#" _
Inherits="MSDN.SharePoint.Samples.ContentpageTemplate, _
MSDN.SharePoint.Samples.SharePointPagesWithCodeBehind, Version=1.0.0.0, _
Culture=neutral, PublicKeyToken=ae015afe5f30fb68" %>
<%@ Master language="C#" Inherits="MSDN.SharePoint.Samples.MinimalMasterTemplate, _
MSDN.SharePoint.Samples.SharePointPagesWithCodeBehind, Version=1.0.0.0, _
Culture=neutral, PublicKeyToken=ae015afe5f30fb68" %>

At this point the code-behind file is wired up to the page layout or master page and developers can do everything they are used to doing within ASP.NET 2.0 development, such as overriding the OnLoad() method or bind data to controls on the page.
Read It

Adding code-behind files in ASPX or ASCX files within a traditional ASP.NET 2.0 environment is quite simple thanks to Microsoft Visual Studio. All a developer has to do is right-click the file in Visual Studio either in Solution Explorer or in the designer, and then click View Code. Visual Studio then creates a new code-behind file (if one did not already exist), adds in the minimal code for the new class to inherit from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class, and then adds the necessary information to the Inherits attribute in the Page or Control directive in the ASPX or ASCX file. This tells the Microsoft .NET Framework where to find the associated class for the file. Developers must inherit from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class and not the System.Web.UI.Page class, as the former dynamically sets the master page URL using the current site's CustomMasterUrl property. Unfortunately, Visual Studio can't do the same things for custom page layouts used in MOSS 2007 publishing sites. Instead the developer must do these things manually. The same is true for master pages in SharePoint sites.

One word of caution: Do not add inline code to the page. Put all code in a code-behind file. Why? Because when a page is uncustomized (or when the source of the page is still pulled from the file on the file system rather than from the database), MOSS allows the page to run normally. However, if the page is customized by using a tool such as Microsoft Office SharePoint Designer 2007, the page is run through the MOSS safe mode parser, which will block any inline code from running.

This article refers to Microsoft Office SharePoint Server 2007 (MOSS 2007) Beta 2 Tech Refresh. Details are subject to change in the RTM version.

One of the MOSS 2007 buzzwords is master pages. But what all does that entail? How does the master page work with the content in the site and how do we do things like add web part zones and field controls? To aid and benefit SharePoint designers and those of us assigned to user interface customization, here is a break down of the relationships between master pages, page layouts, controls and content types. This is not a technical breakdown with sample code, this is just to explain the relationships between these core concepts in MOSS 2007.

Master Pages

Master pages are not a new concept or feature unique to SharePoint. Master pages were introduced with ASP.NET 2.0 as a way to centrally house and control the layout and design of a web site or application. A single master page file can control the look and feel of countless pages within a site/application. It is basically a next generation approach of how to include common content in lieu of frames or server side include files.

There is a lot of documentation already out there about master pages, and much of the knowledge can easily be utilized for developing and implementing master page files for SharePoint.

Content Pages

Content pages is the other half of master pages. Master pages store the layout and design, while content pages define the content. The content page is bound to a master page. Together the two create the presentation layer of content for a site/application.

In SharePoint content pages are called Page Layouts. But they work similar to content pages. The master page file is combined with the page layout to create the presentation layer of content for the SharePoint site.

Master Page and Page Layout combine to create the rendered page
Master Page and Page Layout Create the Rendered Page

Master Page/Content Page Resources

The Components of a SharePoint Master Page File

The master page will contain all of the user interface layout code for the site. This includes CSS, JavaScript and HTML. Examples of what you would put in the master page:

Header code including company logo and branding images
Navigation
Footer code including copyright statements and links
CSS (cascading style sheet) styles
Body background colors, images or styles
Common JavaScript functions

The other core component that is used in a master page file are the Content Placeholders. A Content Placeholder is just that, a location flagged as where content will be inserted. The content is stored in the page layouts. The content placeholders designate where the content from the page layout will be inserted in the master page. So for example, a simple master page could flow like this:

Registry tags, opening HTML/Body tags
CSS Styles
JavaScript Functions
HTML code for the header
Content Placeholder for the main content of the page
HTML code for the footer
Closing Body/HTML tags

A Content Placeholder looks like this:

Content Placeholders can be wrapped in HTML code, for example DIV, SPAN or TABLE tags. A good way to think about it is everywhere you would place content that you would like to have customized for each page, insert a Content Placeholder.

There are a set of required Content Placeholders for SharePoint. Without these placeholders, the site will not work. If you don't want to display all of the placeholders on your site, you can hide the placeholders by grouping them in a hidden ASP:Panel control, or individually set each placeholder with a visibility of false (visible="false").

Nesting and components of a Master Page File

For a full list of the content placeholders used in SharePoint, refer to the SDK (list to be included on this site in the future). For the base code including the bare minimum needed for a SharePoint master page, refer to this article:

How to: Create a Minimal Master Page

The Components of a Page Layout File

The page layout contains all of the Content Controls that match the content placeholders from the master page file. For example, the matching content control from our sample master page content placeholder from above would look like this:

Insert field controls, web part zones or HTML code here

Page layout content should be content that will change from page to page, for example:

Title, Author, Byline
Body Text

With the exception of the Registry tags, nothing can be outside of a content control in the page layout file! If you try to wrap HTML or add extra code outside of the content control, it will break the page.

SharePoint content is added to the content controls in a page layout in one of two ways, Field Controls or Web Part Zones.

Field Controls are content areas that map to columns in the Content Type. Field control placement is controlled in the page layout file and can't be moved by the content editor through the web interface. They are ideal for situations where excerpts of content need to remain in a fixed location on a site. A field control looks similar to this:

Web Part Zones on the other hand allow content editors to add and move content around on the page. They work very similar to how they did in SharePoint 2003. The web part zone is specified in the page layout, and then the content editor can choose to add, remove or rearrange web parts within the specified zones. A web part zone looks similar to this:

Nesting and components of a Page Layout File

Content Types

Content Types are a new feature/concept of SharePoint 2007. They definitely warrant learning about and gaining an understanding of. A content type is a collection of settings that is applied to a particular category of content that can be reused multiple times. Through content types you can manage metadata and the behavior of a document or item type in a central, reusable way. Please refer to the following additional resources for a more in depth explanation of content types:

Columns from a content type are referenced through the field controls in the page layout. One content type can be reference by multiple page layouts, but a page layout can only reference one content type. This allows you to easily change the page layout of a page in a site without compromising the content since the content is controlled in the content type. The only restriction is to change the page layout to another page layout that is based on the same content type as the original.

Relationship between Content Types and Page Layouts, shown here wrapped with Master Pages. Click for a larger view.

A Few More Core Concepts and We Are Done…

Master Page Inheritance

Master page files can be applied on a site level, but not on a page level. So a sub site can have a different master page specified than the parent, or it can inherit the master page file settings from the parent.

Master page inheritance among sites and sub sites.

The Pages Library

When you create a page on a site, the page is stored in a Pages document library in the content database. A physical file is not created on the web server. The Page settings specify a page layout that can be changed to another page layout (that uses the same content type). Pages can be moved between Page libraries in a site collection. Each site has it's own Pages library. Because the Pages are stored in a library, they can have version history, check in-check out, publishing and workflow capabilities.

Pages library relationships with sites.

The Silo Approach United

All of the components that contribute to the rendered SharePoint page is stored in silos... master page, page layout, page, content type and all the bits in between that link them together. To connect it all:

A Page is stored in a Pages library within a site.
The Page references a Content Type that helps populate the page with data. Content types are stored within a site.
A Page Layout is applied to the Page to control what content appears and where through the use of Field Controls and Web Part Zones. This is specified within the Content Controls in the Page Layout.
A Master Page is applied to the site to wrap on the look and feel and control content placement from the Page Layout through the use of Content Placeholders.

A snapshot of the silos layered together to create the rendered page...
Pages Library