Developing Sharepoint Server 2007 Publishing Sites the Smart and Structured Way

Excerpt from Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs

By Andrew Connell

The latest release of the SharePoint platform, Microsoft Office SharePoint Server (MOSS) 2007, introduces new capabilities to the SharePoint platform: hosting content-centric Web sites on SharePoint and providing a robust publishing infrastructure. This publishing infrastructure enables site owners to delegate to certain individuals the creation and management of content on the site. Other users have rights to approve and publish content for readers to see. Interwoven in this process is a robust controlled publishing infrastructure founded on the Windows Workflow Foundation (WFF). Combined with significant performance enhancements and improvements to the underlying foundation of MOSS, Windows SharePoint Services (WSS) v3, SharePoint is now capable of hosting content-centric Internet sites! This component of MOSS 2007 is commonly referred to as Web Content Management (WCM), and sites utilizing the WCM features are called Publishing sites.

A major component to Publishing sites is the development story: the process behind constructing a content-centric site. Most development concepts surrounding Publishing sites are really SharePoint concepts, because a Publishing site is just another WSS site with some extra functionality. So, how are you supposed to develop a Publishing site? To date, only one approach has been the leader in the WCM community. This is the approach you will find in virtually all documentation, every whitepaper, every Webcast, every conference or trade show presentation, and every magazine article. However, this approach poses certain challenges in the real world when many organizations have a strict change control process.

An alternate development process is presented in this article. It addresses many of the pitfalls associated with the conventional approach. Though many of the concepts in this article are tailored to work specifically with Publishing sites, they will also work with little or no modifications in general WSS v3 sites. Before any concerns arise from the process outlined in this article, rest assured everything is 100 percent supported by Microsoft. In fact, this is the process Microsoft’s out-of-the-box site templates (Collaboration Portal and Publishing Portal) utilize to create the site infrastructure and layout files to implement the default sites!

Another (and arguably better) option is to leverage the Feature and solution framework, a new addition in WSS v3.

Using Features and Solutions to Deploy Site Infrastructure and Layout Files

Both site infrastructure and layout files can be implemented with XML files in Features. Among their various capabilities, Features can be used to create site columns (also known as fields), content types, and provision files. Using these capabilities, developers can create a Feature (or multiple Features) that create the site infrastructure (site columns and content types) and layout files (master pages, page layouts, and so on), package up the Feature(s) into a solution file, and share it with other development team members, or hand it off to environment administrators to implement the changes to the production systems.

The ideal way to implement a Publishing site’s site columns, content types, and add files (also called file provisioning) is using a Feature(s) and deploying the Feature(s) with solutions. Quite simply, it offers developers the most granular control and the easiest way to implement the necessary elements in various environments.

Creating a Feature

NOTE

All files used in the following demonstration are available for download from the download page for Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs.

The first step in this alternate approach is to create a Feature. To create a Feature, create a new directory named

AlternativeApproach

in the following location:

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATESFEATURES.

All Features must contain a Feature definition file, so create a new XML file in Visual Studio 2005 named

feature.xml

and save it in the

AlternativeApproach

directory.

With

feature.xml

open in Visual Studio 2005, add the following code to the file to create the Feature definition. (Table 1 contains a list of the most common attributes used in the

<Feature>

node.)

<?xml version="1.0" encoding="utf-8"?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="6B0480D2-009A-49c1-9DCB-EBF5F7358873"
         Title="Alternative Approach Feature"
         Description="Creates site columns, content types, 
		 a master page, and page layouts for a Publishing site."
         Scope="Site"
         Hidden="FALSE">
</Feature>

Table 1: Feature Element’s Attributes

ATTRIBUTE DESCRIPTION
<font size="2">Id</font>
Unique ID (a GUID without brackets) of the Feature. This is required.
<font size="2">Title</font>
Name of the Feature to be displayed on the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional and limited to 255 characters.
<font size="2">Description</font>
Description of the Feature to be displayed on the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional.
<font size="2">Scope</font>
One of four values:

<font size="2">Farm</font>

(applies to all sites in the entire SharePoint farm),

<font size="2">WebApplication</font>

(applies to all SharePoint sites within the Web application it was activated in),

<font size="2">Site</font>

(applies to all sites within a site collection), or

<font size="2">Web</font>

(applies to the specific Web it was activated in). This is required.

<font size="2">Hidden</font>
If

<font size="2">True</font>

, the Feature is not displayed in the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional (default value is

<font size="2">False</font>

).

<font size="2">Version</font>
This optional value can be used to version the Feature. The format to use is:

<font size="2">[#.#.#.#]</font>

.

Only one attribute needs to be highlighted here:

Scope

. When creating site columns and content types,

Scope

can be

Site

or

Web

. However, when provisioning files, it should be

Site

.

NOTE

For more information on the

&lt;Feature&gt;

node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms475601.aspx.

Creating Site Columns with Features

With the shell of a Feature created, the next step is to create an element manifest file that will create a site column. Create a new XML file in Visual Studio 2005 named

SiteColumn.xml

and save it in the

AlternativeApproach

directory.

Then, add the element manifest file to the Feature by adding the following code between the

&lt;Feature&gt;&lt;/Feature&gt;

tags in the

feature.xml

file:

<ElementManifests>
  <ElementManifest Location="SiteColumn.xml"/>
</ElementManifests>

Next, add the following code to

SiteColumn.xml

that will create the site column when the Feature is activated. (Table 2 contains a list of the most common attributes used in the

&lt;Field&gt;

node.)

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Field ID="{C3AA9C21-81F7-41d7-B5A5-CBEB40768C46}"
         Name="AlternateApproachColumn"
         DisplayName="Alternate Approach Column"
         Group="WROX"
         Type="Text" />
</Elements>

Table 2: Field Node’s Attributes

ATTRIBUTE DESCRIPTION
<font size="2">ID</font>
Unique ID (a GUID with brackets) of the site column. This is required.
<font size="2">Name</font>
Unique name for the new site column. This is the internal name used by SharePoint to uniquely identify the column within a list. This value will never change. This is optional. If not specified, the

<font size="2">Name</font>

is automatically generated based on the

<font size="2">DisplayName</font>

of the column.

<font size="2">DisplayName</font>
The user-friendly name of the column that appears in the SharePoint browser-based interface, such as the column name when a list is displayed in table format. This is optional.
<font size="2">Group</font>
Specifies the site column group that the site column will be added to. This is optional.
<font size="2">Type</font>
The data type of the field.

NOTE

For more information on the

&lt;Field&gt;

node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms437580.aspx.

Creating Content Types with Features

The next step is to add a content type to the Feature. Create a new XML file in Visual Studio 2005 named

ContentType.xml

and save it in the

AlternativeApproach

directory.

Then, add the element manifest file to the Feature by adding the following code between the

&lt;ElementManifests&gt;

tags, just after the existing

&lt;ElementManifest&gt;

tag in the

feature.xml

file:

  <ElementManifest Location="ContentType.xml"/>

Next, add the following code to

ContentType.xml

that will create the content type when the Feature is activated. (Table 3 contains a list of the most common attributes used in the

&lt;ContentType&gt;

node.)

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType 
ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3
DB064584E219954237AF3900213FEEC23C37400bBEC425C10E76F37F
"
               Name="Alternate Approach Content Type"
               Group="WROX">
    <FieldRefs>
      <FieldRef ID="{C3AA9C21-81F7-41d7-B5A5-CBEB40768C46}" 
                Name="AlternateApproachColumn" />
    </FieldRefs>
  </ContentType>
</Elements>

Table 3: ContentType Node’s Attributes

ATTRIBUTE DESCRIPTION
<font size="2">ID</font>
Unique ID of the content type. This is required. For more information on content type IDs, refer to the note following this table.
<font size="2">Name</font>
The name of the content type. This is required.
<font size="2">Group</font>
Specifies the content type group that the content type will be added to. This is optional.

NOTE

For more information on the

&lt;ContentType&gt;

node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/aa544268.aspx.

Two things need some explanation in the preceding code snippet.

First, the content type ID is a unique ID that every content type requires. Every content type must inherit from another content type; no content type can exist without a parent. The first part of the content type ID (up to the third instance of 00) represents the ID of the content type’s parent. In the preceding code snippet, this is the

Page

content type that is created by MOSS when provisioning a new Publishing site. The latter part of the content type ID (

00213FEEC23C37400bBEC425C10E76F37F

) is what makes this content type unique from other content types.

NOTE

For more information on content type IDs (a complex subject), refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/aa543822.aspx.

Second, note that the

&lt;FieldRef&gt;

node’s

ID

and

Name

attributes are the same as the site column previously created. This is how a site column is added to a content type.

Provisioning Files with Features

Now that the site infrastructure components have been created and added to the Feature, the next step is to create the element manifest file that will provision the master page and page layout, each using a specific preview image. Create a new XML file in Visual Studio 2005 named

ProvisionFiles.xml

and save it in the

AlternativeApproach

directory.

Then, add the element manifest file to the Feature by adding the following code between the

&lt;ElementManifests&gt;&lt;/ElementManifests&gt;

tags, just after the existing

&lt;ElementManifest&gt;

tag in the

feature.xml

file:

<ElementManifest Location="ProvisionFiles.xml"/>

Next, add the following code to

ProvisionFiles.xml

that will provision the files when the Feature is activated. (Table 4 contains a list of the most common attributes used in the

&lt;Module&gt;

node, and Table 5 contains a list of the most common attributes used in the

&lt;File&gt;

node.)

 
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- provision master page -->
  <Module Name="WROXMasterPages" 
          Url="_catalogs/masterpage" 
          Path="" 
          RootWebOnly="TRUE">
    <File Url="ACminimal.master" 
          Type="GhostableInLibrary">
      <Property Name="ContentType" 
                Value="$Resources:cmscore,contenttype_masterpage_name;" />
      <Property Name="PublishingPreviewImage" 
                Value="~SiteCollection/_catalogs/masterpage/Preview Images/wrox.jpg, 
	~SiteCollection/_catalogs/masterpagePreview Images/wrox.jpg" />
      <Property Name="Description"
                Value="Provisioned from the AlternativeApproach Feature. "/>
    </File>
  </Module>
  <!-- provision page layout  -->
  <Module Name="WROXPageLayouts"
          Url="_catalogs/masterpage"
          Path=""
          RootWebOnly="TRUE">
    <File Url="AltApproachPageLayout.aspx"
          Type="GhostableInLibrary">
      <Property Name="ContentType"
                Value="$Resources:cmscore,contenttype_pagelayout_name;"/>
      <Property Name="PublishingAssociatedContentType" 
                Value=";#$Resources:cmscore,
contenttype_articlepage_name
;;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3D
B064584E219954237AF3900242457EFB8B24247815D688C526CD44D;
#"/>
      <Property Name="PublishingPreviewImage" 
                Value="~SiteCollection/_catalogs/masterpage/Preview Images/wrox.jpg, 
~SiteCollection/_catalogs/masterpagePreview Images/wrox.jpg" />
      <Property Name="Description"
                Value="Provisioned from the AlternativeApproach Feature"/>
    </File>
  </Module>
  <!-- provision preview image -->
  <Module Name="WROXPreviewImages" 
          Url="_catalogs/masterpage" 
          Path="" 
          RootWebOnly="TRUE">
    <File Url="wrox.jpg" 
          Name="Preview Images/wrox.jpg" 
          Type="GhostableInLibrary"/>
  </Module>
</Elements>

Table 4: Module Node’s Attributes

ATTRIBUTE DESCRIPTION
<font size="2">Name</font>
Name of the file set. This is required.
<font size="2">Url</font>
Address of the folder, relative to the top-level Web in the site collection, where the files in the set will be provisioned. This is optional.
<font size="2">Path</font>
Address of the folder, relative to the

<font size="2">Feature</font>

, where the files to be provisioned reside. This is optional.

<font size="2">RootWebOnly</font>
When set to

<font size="2">True</font>

, the files in the set are installed only in the top-level Web within the site collection. This is optional.

Table 5: File Node’s Attributes

ATTRIBUTE DESCRIPTION
<font size="2">Url</font>
Path to the file. This is combined with the

<font size="2">Path</font>

attribute in the parent

<font size="2">&lt;Module&gt;</font>

node to determine the physical location of the file in the Feature. This is required.

<font size="2">Type</font>
When provisioning files, this should always be set to

<font size="2">GhostableInLibrary</font>

. The other option,

<font size="2">Ghostable</font>

, applies only to files that are not added to SharePoint libraries. This is optional.

In the preceding code snippet, notice that the master page is provisioned, followed by the page layout, and finally the preview image used by both files is added to the site. Each

&lt;Module&gt;

node contains at least one

&lt;File&gt;

node, which contains optional

&lt;Property&gt;

nodes.

Module Node Overview

The

&lt;Module&gt;

node, signifying a file set, contains a few attributes that define the common aspects of the file set. The

Url

attribute specifies the target SharePoint library where the files in the set should be provisioned.

Path

is the local, Feature-relative path where the files are located. In the case of the Feature in the preceding code, because all files are in the root directory, no path is necessary. If the master page and page layout were in the

LayoutFiles

directory within the Feature,

Path

would be set to

LayoutFiles

. The last attribute,

RootWebOnly

, specifies that the files are provisioned only in the top-level Web of the site collection the Feature is activated in. In the case of Publishing sites,

RootWebOnly

should always be set to

True

.

NOTE

For more information on the

&lt;Module&gt;

node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms434127.aspx.

File Node Overview

Modules are essentially file set groupings. Each

&lt;Module&gt;

node contains one or more

&lt;File&gt;

nodes. All files in a set will follow the directives set in the set they belong to, defined in the

&lt;Module&gt;

node. The

Url

attribute specifies the location of the file in the feature. This is combined with the

Path

attribute defined in the

&lt;Module&gt;

that contains the

&lt;File&gt;

node.

Although optional, the other attribute that should always be included in the

&lt;File&gt;

node is

Type

, which, when specified, dictates the file should be cached in memory on the SharePoint WFE server, regardless of the value. There are two possible values for

Type

:

Ghostable

and

GhostableInLibrary

.

Ghostable

is used when files are not stored in a library or gallery. In the case of a Publishing site, when provisioning files, this value should never be used because master pages, page layouts, images, CSS — they will all reside in a library in the top-level Web of the Publishing site collection. Therefore, always specify

GhostableInLibrary

here.

NOTE

For more information on the

&lt;Module&gt;

node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms459213.aspx.

Property Node Overview

&lt;Property&gt;

nodes are contained within

&lt;File&gt;

nodes. These elements are used to specify the value of the fields within the SharePoint library the file is provisioned into. For example, for the master page and page layout files in the previous code snippet, three properties are specified:

  • ContentType

    — This value specifies the content type of the item. For master pages and page layouts, developers should use localized values. The master page localized value is

    $Resources:cmscore,contenttype_masterpage_name;

    and the page layout localized value is

    $Resources:cmscore,contenttype_pagelayout_name;

    .

  • PublishingAssociatedContentType

    — This is the content type that is associated with the page layout. The associated content type is the content type that defines the schema of the page. The value contains a delimited string which includes the name of the content type as well as the content type ID.

  • PublishingPreviewImage

    — This is the value where the preview image can be found. The field type of the

    PublishingPreviewImage

    field is of type

    URL

    . This explains why the preview image value is specified as a comma-delimited string with two values. One value is used as the description for the URL, and the other is used for the target. In the previous code snippet, the same address was used for both values, so content owners and administrators can easily identify where the image is located.

NOTE The address of the preview image is pointing to the image that is provisioned at the end of the code snippet.

  • Description

    — This field is used to enter a user-friendly description of the file.

Notice that no properties are specified for the preview image provisioning. None are required, and in this demonstration, none were specified to simply add variation to the code snippet.

As with any process, there are advantages and disadvantages to using Features and solutions to implement a Publishing site’s infrastructure and layout files. Regardless of the advantages and disadvantages of this approach (which are discussed in Chapter 4, "Developing Publishing Sites The Smart And Structured Way," of Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs (Wrox, 2007, ISBN: 978-0-470-17402-9). This is still the most preferred method in the development of a Publishing site.

This article is excerpted from Chapter 4, "Developing Publishing Sites The Smart And Structured Way," of Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs (Wrox, 2007, ISBN: 978-0-470-17402-9). Andrew Connell is an independent consultant, instructor, and Microsoft Office SharePoint Server MVP with a focus on Web Content Management. He is one of the 16 Microsoft SharePoint MVPs who contributed their expertise in the specific SharePoint area that interests them most for this book. He has authored and co-authored numerous books on the subjects of Microsoft Content Management Server and SharePoint, including the first published books on the latest release Windows SharePoint Services (WSS) v3 and Microsoft Office SharePoint Server (MOSS) 2007. Connell has spoken on the subject of Office SharePoint Server 2007 development and Web Content Management at various community events in the southeast United States, as well as national conferences such as TechEd, SharePoint Connections, VSLive, and the Microsoft SharePoint Conference. You can follow him at his popular SharePoint and Web Content Management-focused blog at http://www.andrewconnell.com/blog.

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *