Designing Your MCMS 2002 Solution for Reusability

Microsoft Corporation
September 2005

Applies to:
    Microsoft Content Management Server 2002

Summary:  Use best-practice design recommendations for Microsoft Content Management Server 2002 applications and Web sites to help you create your site in a way that prepares it for future versions of MCMS technology. (8 printed pages)

Contents

Introduction

Microsoft recently announced that the next generation of its Web content management technology will be released as part of Microsoft Office "12", the code name for the next version of the Microsoft Office System. The new offering will succeed Microsoft Content Management Server (MCMS) 2002. Office "12" will provide seamless integrated Web content management and portal capabilities that will share a common, scalable architecture built on the next-generation Microsoft Windows SharePoint Services foundation. The new release will provide significant enhancements and new capabilities for page authoring, workflow and approval, content deployment and overall site administration and management. Office "12" is expected to be available in the second half of calendar year 2006.

The best practices and tips contained in this article can help you create your site in a way that prepares it for the next version of the technology. We discuss the following best practices:

Finally, we've included a few best practices for template files and some tips for URLs.

Important   Because service packs and other tools rely on the MCMS database structure remaining the same, you should never change the MCMS database structure or access data from the database itself. Instead, use the MCMS APIs to retrieve the information.

Timeline

Between now and when the next version of the technology is released, we plan on releasing MCMS 2002 Service Pack 2 (SP2) to support Microsoft SQL Server 2005, Microsoft Visual Studio 2005, and Microsoft .NET Framework 2.0. MCMS 2002 SP2 will support the runtime, and the navigation and authentication provider models, as well as master pages for the .NET Framework 2.0. When MCMS 2002 SP2 is released, we will publish a best practices white paper along with samples to help you develop modular MCMS 2002 applications. At Office "12" public beta, we will provide content on how to prepare and move to the next version of the technology.

 Timeline for release of MCMS 2002 SP2 and related products

Figure 1. Timeline for release of MCMS 2002 SP2 and related products

Creating Site Navigation

Navigation is a primary customization performed on most MCMS sites. Navigation often consists of one or more custom Microsoft ASP.NET controls that define the navigation of your MCMS site. You then add these custom controls to each page template that you define for the site.

On the WoodgroveNet sample site, you can find three navigation controls: MCMSBreadcrumb, MCMSDHTMLGlobalNavigation, and LeftNavigation. The following figure shows the LeftNavigation control.

 WoodgroveNet LeftNavigation control

Figure 2. WoodgroveNet LeftNavigation control

Note   To download the WoodgroveNet sample site, go to WoodgroveNet sample site.

In general, you create custom navigation for an MCMS site by using the Publishing API to traverse the channel structure, and formatting each navigation link as you go.

The following figure shows the original navigation server control model. The navigation control connects directly to the MCMS Publishing API to retrieve the channel and posting structure. Then the navigation control displays the structure with the proper formatting. One of the examples provided in the first MCMS 2002 Help file shows a navigation server control constructed in this way.

Original navigation server control model

Figure 3. Original navigation server control model

Since the introduction of this original model, we have learned a better way to create navigation: abstract business logic from display logic in separate modules. In other words, isolate formatting or look-and-feel code from the channel-traversing code by using a navigation control and a data abstraction layer that provides the MCMS channel structure. When the page is displayed, the navigation control connects to the data abstraction layer, which then retrieves the channel hierarchy from MCMS. By keeping the formatting code separate from the business logic, you can now update or replace the business logic without redoing the formatting code.

The following figure shows a more modular solution for navigation.

Modular navigation model

Figure 4. Modular navigation model

If you are already using or reading up on Microsoft Visual Studio 2005 (code name "Whidbey"), you will find this navigation model very familiar. For more information, see Walkthrough: Adding Site Navigation to a Web Site.

One great benefit of this modular model is that you can use any existing Web control for your navigation, if it contains a way to bind to the MCMS hierarchy control. For examples of controls that you can use for Web site navigation, see the ASP.NET tree Control Gallery.

Creating Forms-Based Authentication

Forms-based authentication is a type of ASP.NET-based authentication in which an unauthenticated user is directed to an HTML form. After the user provides credentials, the system issues a cookie containing a ticket. On subsequent requests, the system first checks the cookie to see if the user was already authenticated.

The following figure shows the original forms-based authentication model. One of the examples we provided in the first MCMS 2002 Help file shows a logon page constructed in the following way.

Original forms-based authentication model

Figure 5. Original forms-based authentication model

Since the introduction of this original model, we have learned a better way to create authentication: separate business logic from display logic in modules.

In practice, this means you should isolate your formatting, or look-and-feel code, from the authentication code by creating a forms logon control, and then linking it to a data abstraction layer that performs MCMS authentication.

The following figure shows a more modular solution for forms-based authentication.

Modular forms-based authentication model

Figure 6. Modular forms-based authentication model

If you are already using or are reading up on Visual Studio 2005 (code name "Whidbey"), you will find this authentication model very familiar. For more information, see How to: Implement Simple Forms Authentication.

Creating Custom Placeholder Controls

Placeholders are areas in a template that authors use to add content to each page that is based on that template. A placeholder control is an ASP.NET-based server control that provides the user interface for a placeholder in both the authoring and presentation modes of the MCMS Web Author, which content contributors use to create content. You can create specialized user interfaces by creating custom placeholder controls.

We designed the custom placeholder control model so that you can create modules rather than writing a lot of code in the control class. For example, you can create a custom placeholder control that in authoring mode displays a drop-down list, and in presentation mode displays the selection as text. This custom placeholder control uses a DropDownList control for authoring mode and a Literal control for presentation mode.

For information about creating custom placeholders, including an example of a well-designed custom placeholder control, see How to: Creating Custom Placeholder Controls.

Here are two best practices you should follow when you implement custom placeholder controls:

Integrating Other Business Applications

If you want to display information from one of your other business applications on your MCMS Web site, create server controls to contain the logic for accessing and displaying the information, instead of putting the logic directly on the template file. Then place the server controls on your template file, as shown in Figure 7.

MCMS integrated with other business applications through server controls

Figure 7. MCMS integrated with other business applications through server controls

It is a best practice to isolate your business application from your MCMS Web site so that when either changes, you can more easily update the code.

Designing Multilingual Sites

You have many options when designing your multilingual MCMS site. As a best practice, use one of the following options.

Master/Subordinate Channels

When you use Master/Subordinate channels, you author all content in a master channel structure and publish the content to a subordinate channel structure for each language by creating connected pages. Users who browse your site need to navigate only through the subordinate channels. The published view of the site generally does not expose the master channel structure. You can hide it from view completely in published mode by setting the Hide When Published property of the master channels you use.

Parallel Channels

When you are designing a multilingual MCMS site, you should be aware that each market or culture has its own unique channel structure that may or may not have similar schema. The rationale for building multilingual/multicultural support using the parallel channel approach is that some, if not all, of the cultures in your business's requirements will demand significantly different layouts, content organization, and unique content. For most intents and purposes, this approach is similar to maintaining completely separate sites for each target market.

For more information, see the sections "Master/Subordinate Channels" and "Parallel Channels" in Creating Multilingual Web Sites with Microsoft Content Management Server 2002.

Best Practices for Template Files

Every posting in an MCMS Web site is based on a template. A template determines the basic layout for the posting.

As a developer, you create a set of templates from which users can create postings within a site, for example Homepage, Contact Us, Summary, and Plain Text templates. When you modify a template, it affects all of the postings based on that template.

When you create templates for your site, minimize the number you create. Most sites can be implemented with fewer than 30 templates.

Your template files determine the formatting of postings on your site. You might be tempted to put formatting code directly in your template file to describe the look and feel of your postings. However, as a best practice, use cascading style sheet (CSS) files to contain all style information instead of putting formatting directly in the template file. This will also help you ease migration rework for future versions of MCMS technology.

Tips for URLs

MCMS creates URLs from the names you give to channels and postings in the site. For example, a posting named "default" in the Contact channel, which is under the Sales channel, would have the following URL: http://www.contoso.com/Sales/Contact/default.htm.

The following describe three tips for creating MCMS URLs: limit URL length, avoid duplicate URLs, and avoid hard-coded URLs.

Limit URL Length

When you create your channel structure, remember that many products you might want to use now or in the future with your MCMS site have restrictions on URL length. For example, Microsoft Windows SharePoint Services has a limit of 260 characters for URLs (not including query strings).

When you name your channels and postings, consider keeping the names shorter and using the display name property for longer text.

Avoid Duplicate URLs

Try to avoid creating postings, channels, and resources with duplicate URLs. MCMS will make one of the two URLs a "friendly" URL and the other will be an "unfriendly" GUID-based URL.

For example, the first posting named default in the root channel has the following "friendly" URL.

http://www.contoso.com/default.htm

But the second posting, also named default, and also in the root channel, has the following "unfriendly" URL.

http://www.contoso.com/Site/(r55mlrvmfzu5mim4f5au54ql)/Pages/Home.aspx?NRM
ODE=Published&NRORIGINALURL=%2fSite%2fen&NRNODEGUID=%7bFA63ACF4-135C-4832-
B3E4-9AC14E1C7131%7d&NRCACHEHINT=NoModifyGuest

Avoid Hard-Coded URLs

Within your MCMS site, and in other applications that link to your MCMS site, try to avoid creating hard-coded links to MCMS URLs. Following is an example of a hard-coded link to an MCMS posting named default.

<a href="http://www.contoso.com/default.htm">

These URLs break when you move or rename the MCMS posting, for example, if you change the name of the default posting to index.

If you must hard-code an MCMS URL in your application, you can minimize the work to fix it after the URL changes by storing it as a global variable in a web.config file. Then, if the URL changes for any reason, you simply edit the web.config file instead of recompiling your application.

Following is an example of a URL stored in the web.config file.

<configuration>
  <appSettings>
      <add key="myMCMSURL" value="http://www.contoso.com/mypage.htm" />
  </appSettings>
</configuration>

Then in your application, use the following code to retrieve the URL.

ConfigurationSettings.AppSettings("myMCMSURL") 

Conclusion

Now that you have read some of the best practices we have provided in this document, you should be ready to begin design on your own MCMS site.

The most common advice given for developing any application is to write modular code so that you can limit the scope of changes you have to make if the application changes. An MCMS application is no exception.

For navigation, forms-based authentication, and custom placeholder controls, create controls for navigation and abstract the data layer. Also, be sure to isolate your customizations. If you connect to other business applications, use separate modules to contain the business logic. We will provide more best practices guidance at MCMS 2002 SP2 and Office "12" public beta in preparation for the next version.

Additional Resources

For documentation, technical articles, background on MCMS, product overviews, and trial additions, see the following resources: