Branding In Sharepoint

Document Sample
Branding In Sharepoint Powered By Docstoc
					Customizing and Branding Web Content Management-Enabled SharePoint Sites
Understanding Web Content Management and the Default Features
Contents

      WCM Enhancements in Windows SharePoint Services

      Understanding the Page Model

      Customizing a Master Page

      Creating New Page Layouts

      Conclusion

      About the Author

      Additional Resources


WCM Enhancements in Windows SharePoint Services

Windows SharePoint Services 3.0 introduces a number of major improvements to the way
you store and manage information and documents in lists and document libraries. Let us
first review these improvements because they form the basis on which a lot of the WCM
features are relying. Here is the list of enhancements discussed:

      General enhancements

      Site columns

      Extensible field types

      Content types

General Enhancements
Versioning of content stored in lists and document libraries has changed significantly in
Windows SharePoint Services 3.0. Lists support versioning now, and document libraries let
you differentiate between minor (draft) and major (published) versions (Figure 1). The
concept of minor and major versions is important in any Web content management system.
Minor versions of pages are not exposed to everybody—only to the content authors and
visitors of the site with the required permission level. The step from a minor version to a
major version is, in most cases, the result of a workflow, but an authorized user can also
decide to manually publish the minor version as a major version. Major versions of pages
are available to every visitor of the site.
Figure 1. Version history page, which shows all version information for a
document or list item




Windows SharePoint Services 3.0 also introduces a new level for securing your information:
per-item security. If you create a list or document library, by default the new item inherits
the permissions of the parent. You can override that inheritance and define the access
control for the list or document library. In Windows SharePoint Services 3.0 lists and
document libraries, the access control list is passed to every item or document stored, but
again you have the option to continue with that scenario or to override the inheritance and
define your own security settings for the individual item or document. In a WCM scenario,
this means that you can now protect individual pages because, as I detail later in this
article, pages are stored in a normal document library—the Pages library. In a Windows
SharePoint Services 3.0 site, all of the content is also security trimmed. Pages that you are
not allowed to see do not appear in the navigation controls.

Site Columns
When you are designing the containers for storing content in Windows SharePoint Services,
aite columns offer you reusability. You can define a column or field at the level of the site
collection and then associate this column with any of the lists or libraries you have or will
make available on the site (Figure 2). Changes to the site column are, by default, pushed
forward to any container that uses the column. This behavior is, however, a decision that
the administrator can turn off per site column.
Figure 2. Adding site columns




Extensible Field Types
In Windows SharePoint Services, Web designers have a closed set of field types they can
use to define the metadata for a list or library. Windows SharePoint Services 3.0 introduces
new types but also lets developers extend that set of types with custom types. Imagine that
you need to embed a movie or display GPS coordinates in a page. There are no default field
types to work with. You must create your own custom field type definition and deploy it with
custom controls that handle visualization and editing of the data for those types of content.
This approach is useful when you frequently need specific validation or representation of
content on a page. Extensible field types is a topic discussed in Part 2 of this series.

Content Types
Windows SharePoint Services 3.0 introduces content types, which provide a framework for
defining your types of content at the level of the site collection. You can then associate
these definitions with any of the lists and libraries in the site collection (Figure 3). A
definition of a content type can range from something simple to highly complex content.
Simple content could be a collection of dedicated metadata and a template you want to
associate with the type of content. A marketing report is one example. Complex content can
have custom workflows, event handlers, information management policies, and even
customized Microsoft Office InfoPath forms that are used by the 2007 Microsoft Office
system smart clients—for example, Microsoft Office Word 2007—to visualize the content and
let you modify the metadata associated with the content type. An InfoPath template for
capturing timesheet information that is processed automatically in Windows SharePoint
Services is one example.
Figure 3. A document library enabled with multiple content types




Content types are the basis for the page layouts discussed later in this article. As a designer
of a WCM system, one of your tasks is to create one or more page layouts or templates for
your content authors. The first step in this process is the definition of a content type.

Understanding the Page Model

Delivering a publishing infrastructure that lets IT and the developers within your
organization avoid the whole process of content creation and management requires a highly
dynamic page model. This was the core of the whole Web content management story that
was delivered with Microsoft Content Management Server (MCMS) and that is now
integrated in Office SharePoint Server 2007.

The main ingredients are the following:

      Master pages determine the look and feel of your site. The master page also
       exposes the navigation controls that visitors of the site use.

      Page layouts—known as templates in MCMS—define the actual content per page,
       how that content is stored and made available to both content authors and visitors of
       the site, and when and under what policies the content is published.

      Field controls—also known as placeholders in MCMS—are controls on a page that
       have two purposes: They display the content to the visitor of the site, and they offer
       an edit-time canvas for authors. A title of a press release, for example, can be
       rendered as a heading 1 by a field control for a visitor of the site, and it can make
       the title editable via a text box for a content author.

Figure 4 displays the relation between a master page (BlueBand.master) and the page
layout (WelcomeSplash.aspx) for a publishing portal site. Both are used to render the home
page (default.aspx) of the site in your browser. This is the home page of a site based on the
Publishing Portal site definition, a new type of site you can build when you have Office
SharePoint Server 2007 installed in your server farm.
Figure 4. A page based on a master page, combined with a content page formatted
by rules defined in a page layout file




  Note:

 I will use this type of site for the rest of the article. However, everything discussed in
 these articles is usable on any site for which you have activated the Publishing
 Infrastructure features. Another example of such a site is a Collaboration Portal.
Master Pages
In a typical site, some elements are shared across most, if not all, of the pages in the site.
This is true for both highly branded sites (such as an outward-facing customer portal) and
highly controlled sites (such as a corporate intranet portal site). Regardless of the type of
site, master pages contain controls that are responsible for rendering these shared
elements, which include:

      Top and left navigation menus

      Logos
      Search fields

      Page editing controls

      Logon controls

      Any other custom controls you create

Master pages also contain cascading style sheet (CSS) references that define the chrome, or
overall look and feel of the page. Typically, many (if not all) of the pages in your site
collection use the same master page to maintain a consistent brand throughout the site
collection. In some scenarios, however, a single site collection employs multiple master
pages for different areas of the collection. For example, a company's extranet portal might
offer a product support area with an appearance that differs from the rest of the site. In this
scenario, it may be wise to create a master page for support pages to differentiate them
from the rest of the pages in the site collection.

Master pages are stored in the master page gallery, a normal document library at the level
of your site collection. A master page gallery is automatically available when you install
Office SharePoint Server 2007 and create a site collection. It provides all the functionality of
a typical Windows SharePoint Services document library, such as versioning, page creation,
check-in/check-out control, and workflow. Every site in the site collection displays a link to
its own master page gallery in Site Settings. However, the master page galleries at the
site levels are ignored for the page model.

Two types of master pages are stored in the master page gallery, each identified by a
unique icon:

      System master pages define the appearance of form, view, and Web Part Pages.
       For example, compare the page for a document library (such as the master page
       gallery) with the home page of your Internet site.

      Site master pages define the look and feel of the pages published within the site.
       These pages, like the home page, are the ones your visitors see and therefore are
       more important to customize than the system master pages.

Page Layouts
Although master pages control the overall branding of your site, the page layout controls
what content is displayed by a page and how that content is laid out. Page layouts are .aspx
files stored in the master page gallery, containing field controls that are responsible for
rendering that page's content. Each field control can pull data from one or more columns
defined by that layout's content type.

Field Controls
Field controls are responsible for rendering the content inside your page layout. Examples
are a text box, a rich HTML editor, or one of the custom field controls you have created.
Page layouts can also contain more than field controls—they can contain Web Parts. Web
Parts typically display content that is not under the control of the content author. An
example is a Web Part that displays the list of related products for a product that the
content author describes via the field controls.

Customizing a Master Page

All of the publishing pages within a site are automatically tied to a master page. When you
create a subsite, the master page definition is inherited from the parent site, but authorized
users can override that inheritance and associate a new master page stored in the master
page gallery with the new subsite. As an administrator you can find that definition on the
Site Master Page Settings page (Figure 5). You can browse to this page by opening the Site
Settings page of your site (by using the Site Actions menu); in the Look and Feel section,
you find the Master Page link.

Figure 5. Specifying the master page your site uses




On the page, you can review the current site master page and system master page.
Switching to another master page is easy: Simply use the drop-down list that is populated
with the names of all master pages that are stored in the master page gallery at the site
collection level. If you make a change, you can decide to push your change to any of your
subsites where the administrator decided not to override inheritance.

Part 2 of this series guides you through the steps of creating a brand new master page. For
this article, let me show you how you can customize an existing master page. The goal of
our customization is to add a copyright statement at the bottom of every page in the top-
level site.

To modify the sample master page
   1. On the Site Master Page Settings page, verify that the master page to edit is named
       BlueBand.master.

   2. In Microsoft Office SharePoint Designer, click File and then click Open. Select your
       site, and click OK. You might want to disable the Contributor Settings by using the
       Site menu in SharePoint Designer.
   You can also open the master page directly from the master page gallery by using
   the Edit in Microsoft Office SharePoint Designer command in the drop-down list
   for BlueBand.master.

3. Navigate to the master page gallery, which is located under the _catalog node in the
   Folder List pane (Figure 6).


   Figure 6. Master page gallery in SharePoint Designer




4. Double-click BlueBand.master and confirm the check-out request.

   Notice how the master page is structured. Various SharePoint controls are
   responsible for the navigation, the rendering of the title of the site, the logo, and
   much more.

5. In the middle of the file, locate an <asp:ContentPlaceHolder> element whose ID is
   "PlaceHolderMain". That is where the content page is inserted by Windows
   SharePoint Services at run time.


      Note:

    You can find a more detailed discussion of the skeleton of a master page in Part 2 of this
    series.
6. Switch to Code view and insert a new table row under the row that contains
   PlaceHolderMain (Figure 7).


   Figure 7. Modifying the master page by adding a copyright statement




7. Switch back to Design view and select the CSS class for your new table cell.

8. Use the Apply Styles pane to select one of the styles from the CSS files linked with
   the master page (Figure 8).
   Figure 8. Applying a style to a master page element




9. Click the Web Site tab, right-click the BlueBand.master page, and check in the
   page. You need to decide whether the revised page is a minor version or a major
   version. In this case, choose a major version and confirm the request to start the
   content approval.

   The browser displays the master page gallery again.


      Note:

    TopNavFlyouts.master is currently stored with the approval status set to pending.
    Anybody with approver permissions can now approve the change you made.
10. You can see your change affecting every page on a site that uses
   TopNavFlyouts.master, such as is shown in Figure 9.
       Figure 9. The modified pages with the copyright statement at the bottom




Creating New Page Layouts

A good content management system should provide a rich and flexible infrastructure for
creating templates (page layouts). These page layouts are the basis for the pages published
on WCM-enabled SharePoint sites. Office SharePoint Server 2007 makes creating page
layouts an easy process by using the storage enhancements discussed at the start of the
article.

A number of page layouts are readily available for content authors to use. But let me guide
you through the steps of creating your own custom page layout—one for a page that
contains a job posting.

The first step is the creation of a content type. You can create a content type at the level of
the site collection if you open the Site Settings administration page from your top-level site.
From here, you can navigate to the Site Content Type Gallery (Figure 10). You can create
the content type in the Site Content Type Gallery of one of your subsites and scope it to
that site and all of the subsites.



Figure 10. Site content type gallery, which contains all content types that are
available in a site collection




Notice that the gallery is already populated with content types. You can add to this list by
clicking Create in the toolbar.

The first section in the New Site Content Type page specifies the name, description, and
parent of the new content type. Each content type is based on a content type. This lineage
creates a hierarchy that connects to the top-level System content type. You can follow this
hierarchy if you go to a page that details a content type. The top section contains a link to
the parent content type (Figure 11). Clicking the link displays the page defining the parent
content type. You can repeat the process all the way to the top-level content type.

Figure 11. Location of the link to the parent content type




If you select Page Layout Content Types on the New Site Content Type page, you can
see in the Parent Content Type list all of the content types that are the bases for the page
layouts included with Office SharePoint Server 2007. If you select Publishing Content
Types, you can see the base content types such as Page and Page Layout. For this
example, select the first one, Page (Figure 12).



Figure 12. Creating your own Job Postings content type
You can also create your own custom group so that you can differentiate your work from the
content types delivered with Office SharePoint Server 2007.

In the next page you define the details for your content type. The custom fields or columns
you define here are important because later they become field controls that you can add to
a page layout by using SharePoint Designer.

For the job posting example, let's add three columns that capture the information we want
to make available on the page.

To add columns to the content type
   1. The first column, the job title field, is already part of the site columns at the level of
       the site collection. Add the column by clicking Add from existing site columns.

   2. Because the two other fields are not available as site columns, you must create
       them. Click Add from new site column.

   3. For the second column, type the name Job Description and select the type Full
       HTML content with formatting and constraints for publishing.

   4. For the third column, type the name Job Prerequisites and select the type Choice.

       For choice values, add, for example, SharePoint Development, ASP.NET
       Development, C#, Visual Basic 2005, HTML, and QuickBasic. You might want to let
       the content author select multiple options by selecting the Checkboxes (allow
       multiple selections) display option.

Now that you have defined what type of content you want to publish, it is time to create the
page layout or template to be used by the content authors to create the job posting pages.
Page layouts are created from the master page gallery. You can access the master page
gallery via the Site Settings page at the level of your top-level site. Click the Master
Pages and Page Layouts link in the Galleries group.

Remember that the content type you created is your definition of the content available with
this type of page. Therefore, ensure that you select the correct content type at the top of
the New Page Layout page. On this page you also need to enter the name of the file, the
title of the page, and (optionally) a description.

You can also create page layouts in SharePoint Designer.

To create a page layout in SharePoint Designer
   1. In SharePoint Designer, open the site.

   2. Expand the _catalogs node, and right-click the masterpage (Master Page
       Gallery) node.

   3. Point to New and click SharePoint Content.
   4. In the dialog box, click SharePoint Publishing and select Page Layout.

   5. Use the drop-down lists to select your content type group and then the content type
       that you created in the previous steps.

   6. Fill in the name and title of your new page layout.

In both cases—creating the page layout in the browser or in SharePoint Designer—the
controls that enable content authors to communicate with the content are not yet in place.
Your next task is to use SharePoint Designer to place the field controls on the page layout.

From the master page gallery, edit the Job Posting.aspx file. Notice how the Toolbox
displays the list of content fields that you can now drag and drop in the PlaceHolderMain
section (Figure 13). As a designer, you determine the appearance of the page. You can also
tweak the controls by using the Properties box.

Figure 13. Field controls based on the fields from the associated content type




To make the page layout available, you must save, check in, and get the file approved. You
can perform these actions from within the master page gallery.

Now the content authors can use the custom page layout. Depending on the scope and the
permissions, they can use the page layout in all of the sites or are restricted to only one.
Let's assume the role of the content author and use the newly designed page layout.

To create a page based on the Job Posting page layout
   1. In the browser, navigate to a site in your site collection or the site to which you have
       scoped the page layout.

   2. Click Site Actions and click Create Page.

   3. Provide a name and an optional description, and then select the Job Posting page
       layout. Click Create.
   The new page displays the field controls that you placed on the page layout (Figure
   14).


   Figure 14. Page with the field controls you placed by using SharePoint
   Designer




4. To make the page available, check in the page and submit it for approval.

   A user who is a member of the Approvers group can then approve the page and
   change it to a published page (Figure 15) accessible by everyone visiting the site.
   (This assumes workflow is enabled. If not, anyone with approval rights can approve
   the job.)
      Figure15. Approved page as displayed to visitors of the site




Customizing and Branding Web Content Management-Enabled SharePoint Sites
Extending WCM
Contents

     Introduction to Extending WCM

     Understanding the Structure of Master Pages

     Understanding the Default Master Pages

     Building a Custom Master Page

     Adding Cascading Style Sheets

     Customizing the Navigation

     Creating Custom Field Controls

     Customizing the Edit Mode Experience

     Conclusion

     About the Author

     Additional Resources
Introduction to Extending WCM

Although Microsoft Office SharePoint Server 2007 provides a rich site definition for
delivering an Internet presence and Web content management (WCM) infrastructure, most
organizations discover the need to customize and extend the default capabilities. In Office
SharePoint Server 2007, all of the WCM features and the underlying artifacts are highly
extensible.

Understanding the Structure of Master Pages

Each page that a visitor sees in the browser when navigating to an Office SharePoint Server
2007 site is a combination of a master page and a published page based on a particular
page layout (a template). The first article in this series (Customizing and Branding Web
Content Management-Enabled SharePoint Sites (Part 1 of 3): Understanding Web Content
Management and the Default Features) provides a general overview of master pages and
page layouts. Let's go further in this article.

The site master page is stored at the level of the site collection in the master page gallery.
Every site has an association with a master page. The pages published in the site adopt the
appearance and expose the navigation controls defined by the master page.

Office SharePoint Server 2007 is an excellent product to use to explore the various elements
that make up a master page. You can use Microsoft Office SharePoint Designer 2007 to
open one of your sites that uses the WCM features. For this article, I use the Publishing
Portal as an example. In the folder list, expand the _catalogs node and the masterpage
node. Double-click BlueBand.master and confirm that you want to check out the file.
Switch to Split mode so that you have the designer and the code editor visible, as shown in
Figure 1.
Figure 1. BlueBand.master open in SharePoint Designer




SharePoint Framework Controls
Controls whose names are prefixed with "SPSWC", "SharePoint", or "WebPartPages" are the
Web controls or Web Parts that are available via Microsoft.SharePoint.Portal.dll or
Microsoft.SharePoint.dll. They are part of Windows SharePoint Services or the additions
provided by Office SharePoint Server 2007. You find these controls in all sites, even those
that do not have the WCM features enabled.

One example is the control for delivering search in the page. The navigation controls
embedded in the master page are examples of controls that come with Windows SharePoint
Services (Figure 2).

The published pages can contain Web Parts. The master page contains the
SPWebPartManager control, which coordinates the Web Parts embedded in these pages.
Figure 2. Web controls and navigation controls in the master page




Publishing Controls
Controls whose names are prefixed with "PublishingWebControls" and
"PublishingNavigation" are the Web controls that deliver the WCM features for the site.

The PublishingWebControls:AuthoringContainer control, which is provided by
Microsoft.SharePoint.Publishing.dll, creates the top part of the page (Figure 3). It is the
container for the Welcome user control, the Site Actions menu, and the Microsoft
ASP.NET user control that renders the authoring console.

Figure 3. Authoring Container in the master page




The publishing controls that are identified by the prefix "PublishingNavigation" (and also
provided by Microsoft.SharePoint.Publishing.dll) are Web controls not directly visible on the
page. The PortalSiteMapDataSource Web control adds a layer on top of the Site Map
Provider model that is part of ASP.NET 2.0. The ASP.NET 2.0 Site Map Provider model gives
developers a pluggable navigation model in which the user interface (UI) and the data
source are separated. Windows SharePoint Services 3.0 and Office SharePoint Server 2007
add features, of which the most important is security trimming. Figure 4 shows an overview
of the interaction that occurs among the various components that drive the navigation in
your SharePoint sites.
Figure 4. Components of the Site Map Provider model




Three PortalSiteMapDataSource controls are embedded. Each maps to a definition for a
provider within the web.config file of the site. The SiteMapDataSourceRoot control uses
the CombinedNavSiteMapProvider control and is connected to the breadcrumb controls.
As its name suggests, it combines the two other PortalSiteMapDataSource controls into
one. The siteMapDataSource1 control provides the data for the top navigation bar, and
the siteMapDS control provides the data for the vertical navigation control.

ASP.NET User Controls
In addition to the ASP.NET server controls, you also find ASP.NET user controls (.ascx files)
embedded in the master page:

      Welcome.ascx is displayed at the top of your page. You will find this control on all
       of your SharePoint sites (even those that do not use WCM).

      VariationsLabelMenu.ascx is displayed when a page is part of a variation
       hierarchy. The user can quickly jump to the same page in another variation by using
       this control (Figure 5).
      Figure 5. ASP.NET user control that allows users to jump to the same page
       in another language




      PublishingConsole.ascx controls all the steps within the publishing cycle of a page
       (Figure 6). I discuss this control in more detail later, in the section titled Customizing
       the Edit Mode Experience.


       Figure 6. The console used by content authors and anybody involved with
       the publishing cycle of a page




      PublishingActionMenu.ascx is the user control that delivers the Site Actions
       menu, which is different from the user control you use on sites that do not have the
       WCM features enabled.

The last set of controls in the master page is the ASP.NET ContentPlaceHolder controls.
The most important one is the PlaceHolderMain control, which indicates where Windows
SharePoint Services inserts the actual content page.

Understanding the Default Master Pages

Different master pages are available with Windows SharePoint Services 3.0 and Office
SharePoint Server 2007. We have looked in detail at BlueBand.master, but you can use
others as starters.

To explore the differences with the others available, click Site Settings and then, in the
Look and Feel section, click Master Page. On the Site Master Page Settings page you can
change the site master page to any of the master pages stored in the master page gallery:

      Default.master is used for the Windows SharePoint Services team sites. You can
       use the same design for your site.
    You might have the impression that all of the controls discussed are present in
    default.master, but if you open default.master in Office SharePoint Designer 2007,
    you notice that the page does not contain the publishing controls directly. Each
    control is inserted by a DelegateControl control. For example, the following is the
    definition of the Publishing Console in the master page.
    Xml
    <SharePoint:DelegateControl runat="server" ControlId="PublishingConsole"
     PrefixHtml="&lt;tr&gt;&lt;td colspan=&quot;4&quot;&gt;"
     SuffixHtml="&lt;/td&gt;&lt;/tr&gt;">
    </SharePoint:DelegateControl>


    Delegate controls give you a powerful yet flexible approach to determine within your
    Feature which control to display. A Feature can, for example, define two search
    controls in the manifest file, each of them sequenced with a number. At run time, the
    delegate control on the page selects the search control that has the lowest sequence
    number and displays the control to the user. Delegate controls are heavily used by
    Office SharePoint Server 2007 to "light-up" or enable features in areas such as
    navigation and search.
    You should avoid using this master page as the starter for your own custom master
    page if you want to provide a clean WCM infrastructure.


   BlueBand.master, BlackBand.master, and BlueGlassBand.master belong to
    the same family and display both a top navigation bar and a left navigation bar. They
    are good candidates for your sites and good starting points for your own
    customizations.

   BlueVertical.master and BlackVertical.master are master pages that are tuned
    for Internet sites, with a good representation of the WCM-related controls. They offer
    the same look and feel as the three master pages discussed in the previous bullet
    but do not contain the top navigation bar.

   BlueTabs.master is also a valid alternative for the default master page. The
    difference is the tabbed representation of the top navigation bar.

   OrangeSingleLevel.master and BlackSingleLevel.master are variations on the
    BlueBand master pages but with different color combinations.
Building a Custom Master Page

You have various options when you want to create your own custom master page. You can
make a copy of an existing master page and rearrange the controls, modifying the layout
and the look and feel. Or you can start from a blank page and create your own.

Open your site in SharePoint Designer. On the File menu, click New Page. The New dialog
box offers you many choices. Choosing Master Page gives you a blank master page. Be
aware that starting with a blank page involves some work and might create problems
because a blank file does not have all the content placeholders necessary to work with the
page layouts and content pages that are included with Office SharePoint Server 2007. The
following code sample represents the simplest possible master page.

Html
<%-- Identifies this page as a .master page written in C# and registers
tag prefixes, namespaces, assemblies and controls. --%>
<%@ Master language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Register Tagprefix="SPSWC" Namespace="Microsoft.SharePoint.Portal.WebControls"
Assembly="Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="WebPartPages"
Namespace="Microsoft.SharePoint.WebPartPages"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="PublishingWebControls"
Namespace="Microsoft.SharePoint.Publishing.WebControls"
Assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="PublishingNavigation"
Namespace="Microsoft.SharePoint.Publishing.Navigation"
Assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="wssuc" TagName="Welcome"
src="~/_controltemplates/Welcome.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="DesignModeConsole"
src="~/_controltemplates/DesignModeConsole.ascx" %>
<%@ Register TagPrefix="PublishingVariations" TagName="VariationsLabelMenu"
src="~/_controltemplates/VariationsLabelMenu.ascx" %>
<%@ Register Tagprefix="PublishingConsole" TagName="Console"
src="~/_controltemplates/PublishingConsole.ascx" %>
<%@ Register TagPrefix="PublishingSiteAction" TagName="SiteActionMenu"
src="~/_controltemplates/PublishingActionMenu.ascx" %>
<%-- Uses the Microsoft Office namespace and schema. --%>
<html>
  <WebPartPages:SPWebPartManager runat="server"/>
  <SharePoint:RobotsMetaTag runat="server"/>
 <%-- The head section includes a content placeholder for the page
 title and links to CSS and JavaScript files that run on the server. --%>
 <head runat="server">
   <asp:ContentPlaceHolder runat="server" id="head">
     <title>
      <asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" />
     </title>
   </asp:ContentPlaceHolder>
   <Sharepoint:CssLink runat="server"/>
   <asp:ContentPlaceHolder id="PlaceHolderAdditionalPageHead" runat="server"
/>
 </head>

 <%-- When loading the body of the .master page, MOSS 2007 also loads
 the SpBodyOnLoadWrapper class. This class handles .js calls for the
 master page. --%>
 <body onload="javascript:_spBodyOnLoadWrapper();">
  <%-- The SPWebPartManager manages all of the Web part controls,
  functionality, and events that occur on a Web page. --%>
  <form runat="server" onsubmit="return _spFormOnSubmitWrapper();">
    <wssuc:Welcome id="explitLogout" runat="server"/>
    <PublishingSiteAction:SiteActionMenu runat="server"/>
    <PublishingWebControls:AuthoringContainer id="authoringcontrols"
    runat="server">
      <PublishingConsole:Console runat="server" />
    </PublishingWebControls:AuthoringContainer>
    <%-- The PlaceHolderMain content placeholder defines where the
    page content should go for all the content from the page layout.
    The page layout can overwrite any content placeholder from the
    master page. Example: The PlaceHolderLeftNavBar can overwrite the
    left navigation bar. --%>
    <asp:ContentPlaceHolder id="PlaceHolderMain" runat="server" />
    <asp:Panel visible="false" runat="server">
      <%-- These ContentPlaceHolders are necessary only to ensure all
      default MOSS 2007 pages render with this master page. If the
      system master page is set to any default master pages, the only
      content placeholders required are those that are being
      overridden by your page layouts. --%>
      <asp:ContentPlaceHolder id="PlaceHolderSearchArea" runat="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderTitleBreadcrumb runat="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderPageTitleInTitleArea"
runat="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderLeftNavBar" runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderPageImage" runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderBodyLeftBorder"
runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderNavSpacer" runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderTitleLeftBorder" runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderTitleAreaSeparator"
runat="server"/>
      <asp:ContentPlaceHolder ID="PlaceHolderMiniConsole" runat="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderCalendarNavigator" runat
="server" />
      <asp:ContentPlaceHolder id="PlaceHolderLeftActions" runat ="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderPageDescription" runat
="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderBodyAreaClass" runat ="server"/>
      <asp:ContentPlaceHolder id="PlaceHolderTitleAreaClass" runat ="server"/>
    </asp:Panel>
   </form>
 </body>
</html>
This very minimal master page displays only the content of the published page that is
rendered inside the PlaceHolderMain control and the title of the published page. The best
approach to finish this master page is to open the BlueBand.master page and embed in your
own master page the various controls you want to make available:

      The PortalSiteMapDataSource controls and the ASPMenu controls to handle the
       navigation.

      The various ASP.NET user controls to display the Site Actions menu and the
       publishing console.


Adding Cascading Style Sheets

Cascading style sheets (CSS) are used to define the look and feel of your pages. Office
SharePoint Server 2007 delivers several CSS files that contain the various site definitions.
For a WCM-enabled site, they are available through the Style Library at the site-collection
level. You can review the contents by opening the Site Content and Structure page from
the Site Actions menu. The Style Library contains a subfolder for each locale you want
your site to support. You can add localized CSS files in the appropriate folders.

A candidate to use in your custom master page is Band.css. However, you can create your
own CSS file and upload it to the Style Library. To link your master page with one of the
CSS files in the Style Library, use the
Microsoft.SharePoint.WebControls.CSSRegistration control.

Html
<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style
Library/~language/Core Styles/Band.css %>" runat="server"/>
<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style
Library/~language/Core Styles/controls.css %>" runat="server"/>
When working in SharePoint Designer, you see the Apply Styles pane filled with all of the
CSS classes you can associate with the various elements and controls in your page.

The administrator of a site can easily define an alternative CSS URL by using the Site Master
Page Settings page. This option enables you to define new styles (and override existing
ones) without having to edit the master page directly.
  Note:

 You can find more documentation about customizing styles in How to: Customize Styles.


Customizing the Navigation

Three artifacts provide the user with navigation in your pages:

      The site map providers, which are responsible for obtaining the navigation data
       stored in the content database

      SiteMapDataSource controls, which provide an abstraction between the
       navigation control itself and the underlying provider of the navigation data

      UI navigation controls, such as the breadcrumb and the menu displayed in the top
       navigation bar

You can extend and customize at any of these three levels.

Site Map Providers
The role of a site map provider in SharePoint Products and Technologies is the same as for
ASP.NET Web applications. Office SharePoint Server 2007 uses the provider to access the
navigation data stored in the content database and represents this navigation data as a tree
of nodes of type SiteMapNode. The various navigation controls use four site map
providers.

SPSiteMapProvider, SPContentMapProvider, and SPNavigationProvider are part of
the Windows SharePoint Services classes; PortalSiteMapProvider is part of the Office
SharePoint Server 2007 object model. Other providers are available. You can find the
registration of all the providers in the web.config file that is associated with the Microsoft
Internet Information Services (IIS) Web application that hosts your SharePoint sites.

In the majority of cases, these providers are sufficient to deliver the necessary data for your
navigation controls. You can, however, create your own providers and define a custom way
of mapping the data with a tree of nodes in memory so that the data mapping can be used
by your own navigation controls. You can create your custom site map provider by creating
a class that inherits either from the base SiteMapProvider class that is part of ASP.NET or
from one of the SharePoint provider classes. Best practice is the latter approach; for
example, you can subclass the PortalSiteMapProvider. Doing so ensures that you have
the proper caching and security trimming. An example of a custom site map provider is
discussed in the Office SharePoint Server 2007 SDK.

SiteMapDataSource Controls
SiteMapDataSource controls are used by some of the navigation controls such as the
TreeView control and the Menu control. They function as an abstraction layer between the
navigation control and the SiteMapProvider classes. Their primary role is to represent a
view on the navigation data and allow for customization via the various properties or
attributes. One use of the SiteMapDataSource controls is to specify where in the tree of
nodes the navigation controls should start and how many levels should be displayed.
The control I use in my WCM-enabled sites is the PortalSiteMapDataSource control,
which is part of the System.SharePoint.Publishing.Navigation namespace.

UI Navigation Controls
The most-used navigation control is Microsoft.SharePoint.WebControls.AspMenu. This
control offers menu-based navigation. You can set numerous properties either in the HTML
of the master page or programmatically via the object model. Refer to the many ASP.NET
2.0 resources for information about creating your own custom navigation controls.

Creating Custom Field Controls

As I discussed in the first article of this series (Customizing and Branding Web Content
Management-Enabled SharePoint Sites (Part 1 of 3): Understanding Web Content
Management and the Default Features), you use field controls to deliver or capture the
content in a publishing page. The field controls are tightly coupled with the type of field you
define at the level of the content type that is associated with your page layout. For example,
if you add a column named "Job Title" of type Single Line of Text, you see a text box field
control when you are in editing mode and plain text when you are in rendering mode.
Microsoft.SharePoint.Publishing.dll adds several new field types you can use when designing
page layouts.

But what if all of this is not enough? The artifacts that compose the page model are very
extensible. We reviewed the customization of the master pages, but you can also create
extra field controls to capture and display data in a very specific way—one that is not
offered as part of Windows SharePoint Services or Office SharePoint Server 2007.

Creating an Address Field Control
Let me walk you through the process of creating an address field type that we can use as a
normal field type for our SharePoint lists and libraries and as a field control in page layouts.
You can create a field control that is used only in page layouts by inheriting from the field
controls that are part of Microsoft.SharePoint.Publishing.dll.

You must handle different usage modes in your custom field control. These modes include
not only the display mode and the edit mode, but also the design mode. The latter is the
mode in which the field control will be if you drop it on the designer in SharePoint Designer.

Your custom field must appear in the list of field types when creating a new column for a
list, a document library, or a content type. The selection of the custom field renders the part
in the options section you use to set the settings of the custom field and specify any default
values (Figure 7).

The custom address field is associated with an ASP.NET server control rendering of the
default data, as it is defined by using a custom field value.
Figure 7. Adding a column based on the custom address field type




Your custom field also must have the capability of rendering a UI for capturing data when
an item or page is created or when the user enters edit mode for the item or page. You can
create an ASP.NET user control with code-behind logic, such as custom processing of the
data or use of external data sources. Figure 8 shows the custom address field in edit mode
in a portal site scenario, where it is used as a column of a list, and in an Internet scenario,
where it is used as a field control for a specific page layout.
Figure 8. Address field UI in a portal site and in an Internet site




Collaborative Application Markup Language (CAML) and the RenderPattern element make
the address data available in rendering mode. This enables users to see the address in the
SharePoint list or on the published page.

Let us now look at how all of this is accomplished. (References to Microsoft.SharePoint.dll
and System.Web.dll must appear at the top of the code, because the code is compiled into
one Microsoft .NET Framework class library. Ensure you have the appropriate using
statements at the top if you want to follow along with the code.)
The first class defines the value to capture. In our example, the address consists of four
fields: the address (or street), the postal code, the city, and the country. Because an
address is not a single value, the class derives from the SPFieldMultiColumnValue class.
This class, named FieldAddressValue, stores one property per item in the structured
value. The class itself resides in the Litware.CustomFields namespace.

C#
namespace Litware.CustomFields
{
  public class FieldAddressValue : SPFieldMultiColumnValue
  {
    private const int numberOfFields = 4;

     public FieldAddressValue()
       : base(numberOfFields)
     { }

     public FieldAddressValue(string value)
       : base(value)
     { }

     public string Address
     {
       get { return this[0]; }
       set { this[0] = value; }
     }
     public string Zip
     {
       get { return this[1]; }
       set { this[1] = value; }
     }
     public string City
     {
       get { return this[2]; }
       set { this[2] = value; }
     }
     public string Country
     {
       get { return this[3]; }
       set { this[3] = value; }
     }
   }
}
Next, create the custom field itself in the same namespace. The address field is represented
by a class named FieldAddress that inherits from the SPFieldMultiColumn class. An
important method to override is FieldRenderingControl. This method defines the ASP.NET
server control to display in the options section when the column is created. Override
GetFieldValue to return the serialized value stored in the database as type
FieldAddressValue, breaking the value into the four pieces rendered by the control.
C#
  public class FieldAddress : SPFieldMultiColumn
  {
    public FieldAddress(SPFieldCollection fields, string fieldName)
        : base(fields, fieldName)
    {}

     public FieldAddress(SPFieldCollection fields,
                   string typeName,
                   string displayName)
       : base(fields, typeName, displayName)
     {}

     public override BaseFieldControl FieldRenderingControl
     {
       get
       {
           BaseFieldControl fldControl = new AddressFieldControl();
           fldControl.FieldName = InternalName;
           return fldControl;
       }
     }

     public override object GetFieldValue(string value)
     {
       if (string.IsNullOrEmpty(value))
           return null;

         return new FieldAddressValue(value);
     }

   }
Using the same project, create a new ASP.NET server control named AddressFieldControl.
You can derive from one of the existing ASP.NET server controls. Deriving from the
BaseFieldControl control is another option. To make a distinction from the previous types
of classes, a second namespace, Litware.WebControls, is used.

Notice that the ASP.NET server control is not really rendering the UI itself. It is using a
control template that is defined in an ASP.NET user control. This is a new technique in
ASP.NET to separate control data from control presentation. The UI for the server control is
defined in a template embedded in an .ascx file. The ID of that template is connected to the
AddressFieldControl control via an override of the DefaultTemplateName property. The
Value property is overridden because the value of the address field is a composite value.
Notice that CreateChildControls does not really create the child controls. That is the task
of the ASP.NET user control. In CreateChildControls you connect to the UI elements—the
various text boxes—via the FindControl method of the TemplateContainer class. At the
end of the class, default values are retrieved from the XML file that accompanies the custom
field. The three properties defined in the XML file are retrieved via the static
GetCustomProperty method of the Field class.
C#
namespace Litware.WebControls
{
  public class AddressFieldControl : BaseFieldControl
  {
    protected TextBox addressBox;
    protected TextBox zipBox;
    protected TextBox cityBox;
    protected TextBox countryBox;

     protected override string DefaultTemplateName
     {
        get { return "AddressFieldRendering"; }
     }

     public override object Value
     {
       get
       {
           EnsureChildControls();
           FieldAddressValue fieldValue = new FieldAddressValue();
           fieldValue.Address = addressBox.Text.Trim();
           fieldValue.Zip = zipBox.Text.Trim();
           fieldValue.City = cityBox.Text.Trim();
           fieldValue.Country = countryBox.Text.Trim();

            return fieldValue;
         }
         set
         {
            EnsureChildControls();
            FieldAddressValue fieldValue = (FieldAddressValue)value;
            addressBox.Text = fieldValue.Address;
            zipBox.Text = fieldValue.Zip;
            cityBox.Text = fieldValue.City;
            countryBox.Text = fieldValue.Country;

         }
     }

     public override void Focus()
     {
       EnsureChildControls();
       addressBox.Focus();
     }

     protected override void CreateChildControls()
     {
        if (Field == null)
            return;

         base.CreateChildControls();
         if (ControlMode == SPControlMode.Display)
             return;

        addressBox = (TextBox)TemplateContainer.FindControl("addressBox");
        if (addressBox == null)
            throw new ArgumentException("Corrupted AddressFieldRendering template -
missing addressBox.");
        addressBox.TabIndex = TabIndex;
        addressBox.CssClass = CssClass;
        addressBox.ToolTip = Field.Title + " Address";

        zipBox = (TextBox)TemplateContainer.FindControl("zipBox");
        if (zipBox == null)
            throw new ArgumentException("Corrupted AddressFieldRendering template -
missing zipBox.");
        zipBox.TabIndex = TabIndex;
        zipBox.CssClass = CssClass;
        zipBox.ToolTip = Field.Title + " zipcode";

        cityBox = (TextBox)TemplateContainer.FindControl("cityBox");
        if (cityBox == null)
            throw new ArgumentException("Corrupted AddressFieldRendering template -
missing cityBox.");
        cityBox.TabIndex = TabIndex;
        cityBox.CssClass = CssClass;
        cityBox.ToolTip = Field.Title + " City";

        countryBox = (TextBox)TemplateContainer.FindControl("countryBox");
        if (countryBox == null)
            throw new ArgumentException("Corrupted AddressFieldRendering template -
missing countryBox.");
        countryBox.TabIndex = TabIndex;
        countryBox.CssClass = CssClass;
        countryBox.ToolTip = Field.Title + " Country";

         if (ControlMode == SPControlMode.New)
         {
             zipBox.Text = Field.GetCustomProperty("DefaultZip").ToString();
             cityBox.Text = Field.GetCustomProperty("DefaultCity").ToString();
             countryBox.Text = Field.GetCustomProperty("DefaultCountry").ToString();

         }
     }
   }
}
As I mentioned earlier, an ASP.NET user control handles the presentation of the four
controls that compose the user interface when interacting in edit mode with the custom
address field. A RenderingTemplate control with the ID AddressFieldRendering displays
the controls in a simple HTML table.
Xml
<%@ Control Language="C#" Debug="true" %>
<%@Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
<%@Register TagPrefix="SharePoint" Assembly="Microsoft.SharePoint, Version=12.0.0.0,
Culture=neutral,
PublicKeyToken=71e9bce111e9429c" namespace="Microsoft.SharePoint.WebControls"%>

<SharePoint:RenderingTemplate ID="AddressFieldRendering" runat="server">
   <Template>
   <table class="ms-form">
   <tr><td>Address:</td><td><asp:TextBox ID="addressBox" MaxLength="255"
Size="50" runat="server"/></td></tr>
   <tr><td>Zip:</td><td><asp:TextBox ID="zipBox" MaxLength="10" Size="5"
runat="server"/></td></tr>
   <tr><td>City:</td><td><asp:TextBox ID="cityBox" MaxLength="50" Size="15"
runat="server"/></td></tr>
   <tr><td>Country:</td><td><asp:TextBox ID="countryBox" MaxLength="50"
Size="15" runat="server"/></td></tr>
   </table>
   </Template>
</SharePoint:RenderingTemplate>
The final part of the custom field type is the creation of the field type definition file. This is
an XML file named fldtypes*.xml—in this example, fldtypes_Litware.xml. This field type
definition file has three parts. The first part is the metadata for the custom field type. The
second part is three properties made available in a declarative way so that they can be
easily modified. (As discussed, the ASP.NET server control is able to access the values at
run time by using the GetCustomProperty method of the Field class.) The third part is the
CAML definition that handles the presentation of the values of the address field in a
rendering mode. This example is fairly simple, but CAML is a rich markup language for the
representation of this type of data; you can imagine more complex kinds of rendering.

Xml
<FieldTypes>
   <FieldType>
      <Field Name="TypeName">Address</Field>
      <Field Name="ParentType">MultiColumn</Field>
      <Field Name="TypeDisplayName">Address</Field>
      <Field Name="TypeShortDescription">Address (street + nr, zip, city and
country)</Field>
      <Field Name="UserCreatable">TRUE</Field>
      <Field Name="ShowOnListAuthoringPages">TRUE</Field>
      <Field Name="ShowOnDocumentLibraryAuthoringPages">TRUE</Field>
      <Field Name="ShowOnSurveyAuthoringPages">TRUE</Field>
      <Field Name="ShowOnColumnTemplateAuthoringPages">TRUE</Field>
      <Field Name="FieldTypeClass">Litware.CustomFields.FieldAddress, AddressFieldType,
Version=1.0.0.0,
       Culture=neutral, PublicKeyToken=96bdd15c5d632372</Field>
      <PropertySchema>
        <Fields>
           <Field Name="DefaultZip" DisplayName="Default Zip:" MaxLength="10"
DisplaySize="10" Type="Text">
              <Default>1651</Default>
           </Field>
           <Field Name="DefaultCity" DisplayName="Default City:" MaxLength="50"
DisplaySize="30" Type="Text">
              <Default>Beersel</Default>
           </Field>
           <Field Name="DefaultCountry" DisplayName="Default Country:"
MaxLength="50" DisplaySize="30" Type="Text">
              <Default>Belgium</Default>
           </Field>
         </Fields>
      </PropertySchema>
     <RenderPattern Name="DisplayPattern">
        <Switch>
           <Expr><Column/></Expr>
           <Case Value="">
           </Case>
           <Default>
              <Column SubColumnNumber="0" HTMLEncode="TRUE"/>
              <HTML><![CDATA[<BR>]]></HTML>
              <Column SubColumnNumber="1" HTMLEncode="TRUE"/>
              <HTML><![CDATA[&nbsp;-&nbsp;]]></HTML>
              <Column SubColumnNumber="2" HTMLEncode="TRUE"/>
              <HTML><![CDATA[<BR>]]></HTML>
              <Column SubColumnNumber="3" HTMLEncode="TRUE"/>
           </Default>
        </Switch>
      </RenderPattern>

   </FieldType>
</FieldTypes>
Deploying the Address Field Control
The three parts of the custom field type—the .NET assembly, the .ascx file, and the .xml file
with the field type definition—must be deployed in the following manner:

   1. The .NET assembly must be deployed in the global assembly cache.

   2. The fldtypes_Litware.xml file must be copied to the path C:\Program Files\Common
       Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML. Several other field
       type definition XML files are already stored here.

   3. The .ascx file must be copied to the path C:\Program Files\Common Files\Microsoft
       Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES. This folder is
       where you also find the various ASP.NET user controls discussed in the first article of
       this series.

For the custom field type to become a field control when dropped on the page layout file in
SharePoint Designer, you must register the custom field in the SafeControls section of the
web.config file.
Xml
<SafeControl Assembly="AddressFieldType, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=96bdd15c5d632372"
Namespace="Litware.WebControls" TypeName="*" Safe="True"
AllowRemoteDesigner="True" />
After the control is deployed, get it working by executing an iisreset command.

Customizing the Edit Mode Experience

The Page Editing toolbar plays an important role in the publishing cycle of the site pages.
It offers content authors status information about the current page, menus for interacting
with the page, and quick access buttons for the most popular actions given the page status
and context (Figure 9).

Figure 9. Page Editing toolbar




As with most of the WCM-related features discussed so far, you can extend the Page
Editing toolbar to fit the needs of your organization.

The underlying mechanism for the rendering of the Page Editing toolbar is an ASP.NET user
control: publishingconsole.ascx. This user control is located in C:\Program Files\Common
Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES among
the many other ASP.NET user controls. The Page Editing toolbar is built with the concept
of separating the data source and UI control; both the data source and the UI control can be
modified independently.

The data sources are two XML files, EditingMenu.xml and QuickAccess.xml, located in
C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\12\TEMPLATE\LAYOUTS\EditingMenu. For compatibility reasons, the contents of
these two files should not be changed. To customize the console, you can edit two files:
CustomEditingMenu.xml and CustomQuickAccess.xml, found in the Editing Menu folder
under the site collection's master page gallery. The contents of these files can extend and
override the settings contained in their parent files (EditingMenu.xml and QuickAccess.xml).

For documentation about the different elements you can use, refer to the XML schema
named ConsoleConfigurationSchema.xsd, which you can find in C:\Program Files\Common
Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\EditingMenu.
Customizing and Branding Web Content Management-Enabled SharePoint Sites
Creating and Configuring WCM-Enabled Sites
Contents

      Introduction to Creating and Configuring WCM–Enabled Sites

      Creating a Publishing Portal

      Configuring the Site for Forms Authentication

      Allowing Anonymous Access

      Creating Site Variations

      Conclusion

      About the Author

      Additional Resources


Introduction to Creating and Configuring WCM–Enabled Sites

Web content management (WCM) is enabled in Microsoft Office SharePoint Server 2007
through a set of features—many of which rely on Windows SharePoint Services 3.0—that
are discussed in the first article of this series. The second article discussed the extensibility
options you have as a developer. (For links to the first two articles in this series, see
Additional Resources.) To conclude this series, I take an administrator's approach to WCM.
Starting with the steps to create an Internet site, I show you how to configure and tune
your site for anonymous access and forms authentication. I also demonstrate how you can
create and configure site variations.

Creating a Publishing Portal

A company typically hosts an Internet site in its own site collection and a dedicated
Microsoft Internet Information Services (IIS) Web site (a Web application). The steps to
create a site are not much different from the steps you take to create team sites or a portal
site. You actually make the decision very late in the process at the level of the site template
you select. For an Internet site, you select the Publishing Portal template.

To create an Internet site by using Office SharePoint Server 2007, open Central
Administration. In the Application Management section, click Create or Extend a Web
Application. This option enables you to enter all the settings for the creation of a Web
application, the authentication provider (Kerberos or NTLM), and the application pool
configuring the worker process running your Internet site. You can, on this page,
immediately turn on anonymous access at the level of IIS.

After you extend the Web application, you can create a site collection with the top-level site
based on the Publishing Portal template.
Configuring the Site for Forms Authentication

Prior to Office SharePoint Server 2007, Windows SharePoint Services and Microsoft Office
SharePoint Portal Server 2003 relied completely on IIS 6.0 to authenticate visitors to the
sites. Visitors needed a valid Windows account—either a local account or, in a real-world
scenario, typically a domain account.

In Windows SharePoint Services 3.0, the visitor accounts can be stored in and managed
from any identity store. You can configure your Web application to allow everybody to visit
the SharePoint sites that allow anonymous access, and then provide custom authentication
when needed by using Microsoft ASP.NET 2.0 forms authentication and leveraging the
ASP.NET 2.0 authentication provider model. For example, you might have accounts for one
or more visitors responsible for authoring and managing the content in the Internet site.
You can also configure anonymous access in combination with Windows authentication
instead of Forms authentication.

Preparing the SQL Server Data Store
ASP.NET 2.0 provides two default authentication providers: Microsoft SQL Server
Membership and LDAP Membership. If these are not sufficient, the ASP.NET 2.0
authentication provider model enables you to create your own custom membership
providers if you decide to store the accounts in another data store.

Suppose that you want to use Microsoft SQL Server 2005 to store your accounts. How do
you start? First you need a database to store the accounts. You could use any database, but
ASP.NET includes a ready-to-use database named aspnetdb. To create this database in
Microsoft SQL Server 2005, you execute a small command-line tool named
aspnet_regsql.exe. You can find this tool in your Microsoft .NET Framework folder. A
wizard in the tool guides you through the steps to create this database.

Switching the Authentication Mode
The default authentication mode for the new Internet site created is Windows
authentication. If you want to configure the Web application to use Forms authentication,
use the following procedure.

To use Forms authentication
   1. Open Central Administration, and then click Application Management.

   2. In the Application Management page that opens, in Application Security, click
       Authentication Providers.

   3. In the Authentication Providers page that opens, click Default.

   4. In the Edit Authentication page that opens, do the following:

          a. In Authentication Type, select Forms.

          b. In Membership Provider Name, type AspNetSQLMembershipProvider.

   5. Click Save.
This procedure changes the authentication portion of the web.config file for the site to the
following.

Xml
   <authentication mode="Forms">
     <forms loginUrl="/_layouts/login.aspx" />
   </authentication>
Office SharePoint Server 2007 includes a sign-in page that you can replace with a custom
sign-in page. (The BLANKINTERNET site definition also includes a sign-in page definition.)

Populating the Accounts Database
Before you can log on to the Internet site, you must have an account provisioned by the
aspnetdb SQL Server database. Currently, none are defined. Several ways exist to populate
the users table inside the database with custom accounts. For example, you can choose to
execute a stored procedure, or you can use the ASP.NET Web Site Administration tool,
which provides a browser-based front end for the database. I explain the latter method
here.

To open the ASP.NET Web Site Administration tool
   1. In Microsoft Visual Studio 2005, create a blank ASP.NET 2.0 Web application.

   2. Modify the web.config file to set the mode of the <authentication /> element to
       Forms instead of Windows.


       Xml
       <authentication mode="Forms" />
   3. Replace the empty <connectionstrings /> tag with the following.


       Xml
       <connectionStrings>
        <remove name="LocalSqlServer" />
        <add name="LocalSqlServer"
          connectionString="Data Source=.;Initial Catalog=aspnetdb;
          Integrated Security=True"/>
       </connectionStrings>
       This change overrides the <connectionstrings /> definition found in the
       machine.config file.

   4. In the toolbar of Solution Explorer, click ASP.NET Configuration. The ASP.NET Web
       Site Administration tool opens in your browser.

   5. Click the Security tab. Use the links on this tab to add accounts to the aspnetdb
       database.
The machine.config file (located in the config folder of the .NET Framework folder) contains
an entry that directs ASP.NET to SQLExpress. If you always want to use the aspnetdb
database that is created in SQL Server 2005, you might want to modify the
<connectionstrings /> element directly in machine.config. If not, make the change in every
web.config file associated with the Web applications where you want to use the aspnetdb
database in SQL Server 2005. You also need to change the web.config file of the Internet
site and the web.config file of Central Administration. The web.config file of Central
Administration is located in C:\inetpub\wwwroot\virtualdirectories\GUID, where GUID is
unique for your own computer. Consult your IIS manager to determine your GUID.

Defining the Administrator Account
None of the accounts created in the Microsoft SQL Server database have access to the
Internet site. And you do not have a way to get access to the site and define a user as an
administrator of the site. However, Central Administration provides an option to define users
for the Internet site via the Policy for Web Application administrative link on the
Application Management page without having to log on to the site itself. On the page, you
can add one of your custom user accounts and grant it the role of the administrator in the
Internet site. The new administrator can then log on and assign roles to the other custom
accounts. If you are targeting the Internet, use the Default zone.

Figure 1 shows how the People Picker control verifies the names you type against the
accounts stored in the SQL Server database. If the People Picker is not able to verify an
account, a red squiggle appears under the name. If this occurs, verify that you modified the
<connectionstrings /> tag in the web.config file of Central Administration.



Figure 1. Using People Picker control with SQL Server accounts
You can now use the administrator account to sign in to the Internet site. If sign in
succeeds, you see a welcome page and can manage the other user accounts.

Allowing Anonymous Access

The last step is configuring the Internet site to allow anonymous users to visit the site. You
already turned on anonymous access at the level of IIS. There is an additional step to take
in the Internet site itself. Currently the anonymous users do not have any authorization to
access the top-level site. On the home page of the Internet site, you can find a shortcut to
the administration page where you have the option to give anonymous users authorization
to the complete site (Figure 2).

Figure 2. Authorizing anonymous users




To grant access to anonymous users
   1. On the home page of the Internet site, click Enable anonymous access.

   2. In the Change Anonymous Access Settings page that opens, under Anonymous
       users can access, click Entire Web site.

   3. Click OK.

If the Enable anonymous access link has been removed from the home page of the
Internet site, use the following procedure.

To navigate to the Anonymous Access administration page
   1. On the Site Actions menu of the Internet site, click Site Settings.

   2. In the Users and Permissions section, click Advanced Permissions.

   3. On the Settings menu, click Anonymous Access.

You can configure anonymous access per site in your site collection. For example, you can
hide one or more sites from anonymous users and make those sites available only to
authenticated users.
Before you test your anonymous access, explicitly log out by using the Welcome control at
the top of the site.

Creating Site Variations

Site variations are definitely one of the most exciting additions to Office SharePoint Server
2007, making it possible for companies to support multilingual, multidevice, or just plain
multi-anything Web sites. Generally, you use site variations to modify a source site, and
Office SharePoint Server 2007 duplicates those modifications to any variations of this site.

For example, imagine a multilingual scenario in which a company decides to support three
languages for their external Web site: Flemish, Dutch (yes! Flemish is different from Dutch),
and English. Being based in Brussels (Belgium), the company designates the Flemish
version of the site as the master or source site. The content managers perform their work
on the master site. They want to see their work—that is, all of the pages created—
duplicated in an automatic way in the Dutch and English sites. Site variations provided by
Office SharePoint Server 2007 allow you to accomplish this task.


  Note:

 Office SharePoint Server 2007 cannot translate the sites. Translation of the created
 content is typically a step in a custom workflow triggered when a content author
 publishes a page—in this example, in the Flemish site.
Artifacts Enabling Variations
Site variations rely on a number of artifacts:

      First and most important are variation labels. In the multilingual scenario discussed
       earlier, Flemish, Dutch, and English are variation labels. One of your variation labels
       must be the source variation label.

      Office SharePoint Server 2007 allows for a fully scheduled and automatic duplication
       of work done in the source variation label. Administrators determine schedules to fit
       their way of working.

      Site variations use the Windows SharePoint Services solutions framework and
       everything it offers. An internal list named Relationships stores all of the metadata
       involved.

      Resources, such as pictures, can be shared (or referenced) by all variations, or
       administrators can decide to maintain dedicated resources per variation label.

Starting with Site Variations
By default, site variations are not turned on. Site collection administrators must first
configure the site variation settings.

To access the site variations settings
   1. Open a site, such as the Internet site created in the beginning of the article.
   2. On the Site Actions menu, click Site Settings.

   3. On the Site Settings page, under Site Collection Administration, click Variations.

Now you need to decide where you want to start varying the site. Your options are to start
from the top-level site ("/") or from one of the subsites in the site collection. You can use
the Browse button to select a subsite.

You can take control of the duplication process yourself or let Office SharePoint Server 2007
take care of it. You can also configure other options:

      Re-create a deleted page in the variations when the source page is republished. This
       option can enforce the consistency between the variations, but in some scenarios
       you might not want to do so.

      Update Web Parts on target pages. When a content author creates a new source
       page, you might want to have all of your target pages created, but you might not
       want to preserve a link to the source page.

      Notify persons that need to be aware of the creation of new subsites or pages.

      Reuse resources (such as a picture) by simply referencing it, or make a local copy of
       the resource. The latter choice is useful if the resources need to be translated.

Creating Variation Labels
Now you create the variation labels, one for each of the languages you want to support.

To create a label for the source variation
   1. On the Site Settings page, click Variation Labels.

   2. On the Variation Labels page, click New Label.

   3. On the Create Variation Label page, type the name of the label, such as Flemish,
       and a description of the label.

   4. In the Display Name box, type the name that represents the variation in the user
       interface.

   5. In the Locale list, select a locale. If your site variations begin at the top-level site,
       the locale allows your site to switch to the language variation based on the culture
       setting in the browser.

   6. In the Hierarchy Creation section, select the portion of the source variation that
       you want to duplicate to the other variations.
   7. In the Source Hierarchy section, select Set this variation to be the source
       variation. You can have only one source variation.

   8. Select the site template on which to base the site variation.

   9. Click OK.

Next you create all of the other site variation labels that will duplicate the content and
infrastructure created in the source variation. Only the title, description, display name, and
locale are available to set. This is because you already have defined the source variation.
Remember that you can have only one source variation for your site collection.

As a final step, you create the infrastructure by clicking Create Hierarchies in the toolbar
of the Variation Labels page. After Office SharePoint Server 2007 creates the variations, you
see an overview similar to Figure 3.

Figure 3. Variation Labels page




Tuning the Navigation
If you return to the home page of your Web site, you can see three subsites—one for each
of the variation labels (Figure 4). (The Press Releases subsite that is visible in the figure is
not part of the variations infrastructure.)
Figure 4. Three language variations for your Web site




The home pages of your site variations still need to be approved before they are published.
The master page associated with your site contains a small ASP.NET user control named
VariationLabelsMenu.ascx that Office SharePoint Server 2007 displays on your pages
(Figure 5), which allows a user to jump to the corresponding page in other variations.

Figure 5. Variations Label menu




For variations based on language, you probably want to hide the variation sites. Remember
that Office SharePoint Server 2007 directs a user to the appropriate language of the site
based on the locale as defined in the language settings of the browser. So a Flemish visitor
with the Flemish locale set in Internet Explorer sees the Flemish variation. If the specified
locale is not available as a site variation, the user sees the source variation.

You can hide variations from the navigation by clicking Modify Navigation Settings on the
Site Settings page at the Site Collection Level.

Authoring Pages
A content author creating a new page in the source variation sees the page duplicated in the
other variations. The update of the variations can happen automatically, or you can activate
it manually by using the Page Editing toolbar where the Update Variations action is
available.

The pages created in the variations can be involved in a workflow that handles the
translation process. One possible scenario is that a translator is notified by an e-mail
message to navigate to the new page and translate it.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:35
posted:11/6/2011
language:English
pages:46