Brian Wilson : architecture

Branding Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:54:00 GMT

Branding

What is branding? Branding is how you apply an organization's identity to an existing software application through customization of a portal site.

Business Drivers

Establish corporate identity and ownership

With the portal site home page becoming the primary interface between employees, customers and their Web, you should assure that it reflects and reinforces the organization's identity. Portal site users should understand intuitively that they are using an enterprise resource. Users should feel that they are interacting with the organization's portal site rather than a standard software application.

Reinforce enterprise standards

Your organization’s Web site represents your organization just as officially as your Annual Report. A number of organizations have made significant investments in the development of standards to guide the creation of their Web sites. These standards include logos and images, colors, fonts, page layouts, and navigational models. Because a portal site is at the center of an organization's intranet, it must adopt such standards. Standards should promote a common look and feel throughout the organization's Webs to make it easier for users to navigate and find the information they need to do their jobs.

For ease of use

A corporate intranet and Internet site is commonly made up of many different sites, created by diverse parts of the organization using a variety of tools. Any branding effort must ensure the greatest possible consistency with existing sites. You should always place higher priority on usability than on look and feel. A solution's look and feel refers to the visual, attractive elements of its interface; usability, however, is about making it easy for end users to interact with and use the interface.

To create a sense of place

Corporate intranets and Internets can be made up of many loosely connected sites, so any branding effort should communicate a clear "sense of place" to your users so they can understand where they are within the portal site quickly. Common approaches to solving this problem include elements such as breadcrumbs, navigation tress, and page titles.

Branding Standards

Branding of a portal site is the application of an organization's identity to an existing software application through customization of the portal site. It is an important requirement for any portal implementation and it has a significant impact on the end user experience. You typically brand a portal site to meet your organization's intranet and Internet standards and guidelines. By definition no two implementations are the same, making it important to understand both the capabilities of the chosen portal platform and the specific organization requirements.

Following are some common branding requirements (or standards) described by organizations in their intranet and Internet design guidelines.

Color and Style

Applying color and style are the most fundamental elements of branding. You should consider any organization requirements in this area to be essential and probably governed by very strict guidelines. Apply these elements of a brand completely and consistently throughout any solution.

Banner or "Brand Box"

The most common branding requirement is developing a page "banner," also known as a "brand-box" or page "header." This element is common to all pages and most organizations will already have a design in place.

Navigation

Organizations have various requirements for site navigation, typically including one or more horizontal and vertical menus. The location of these menus varies; in particular, you can place the horizontal menu along the very top of the page or immediately below the banner. Menu style also varies; some organizations prefer a "fly out" style, others a collapsible style, and still others their own custom design.

Page Layout

Organizations often have one or more standard screen layouts. These are page designs that define where to position elements such as navigation, banner, footer, and body on a page. You must accommodate any number of these page designs within the portal site design, promoting consistency throughout the intranet and in turn making it easier for people to use.

Features and Functionality

Different organizations refer to certain product features in different ways. For example, some customers refer to items added to the portal site as "News," while others prefer to call these items "Announcements." Accommodating these vocabularies can have a significant impact on overall ease of use. In addition, some organizations want to emphasize some product features over others, making some more obvious or discoverable. These same features may not be relevant to other organizations who may want to hide them altogether. Finally, you must take care to ensure full support for accessibility standards, screen resolutions, and different types of browser.

How SharePoint Renders a Page

Imagine that you have a fictional Web site called foo.com and this is Welcome page for the site.

The Welcome page for the site has been requested by the user.

The table at the bottom of the slide represents the Web page and its content, for example Title or Image. In SharePoint this page is represented as an item in a SharePoint library with a content type that defines what fields are available in the page.

When the request comes in to Welcome.aspx the page has a column defining the view. While the page defines the content it does not own the presentation of the content. For presentation the page must look up its associated page layout. The page layout is another server side .aspx that lives in the database and it defines the view or presentation of the content, for example where the title goes or where the image goes. The Page layout executes controls that render the title, the body, the description from page fields in the page item.

The Page layout doesn’t fully own presentation of content. It must also use a Master Page that defines the common shared look and feel across the site, for example the logo and the positioning of the logo or the presence and position of the search box at the top. Any element that appears across your site will be stored in the Master Page which is also a server side .aspx in the database.

One of the important points in this page rendering process is that data is separate from view. This enables you to make changes easily across your sites.

For example, what if you have a site with 1000 article pages and Corporate Communications decides to replace the image or to change the placement of the image from left to right? You only need to update one page layout and the required change will be reflected in all 1000 article pages. Or what if Corporate Communications decides to update the look of your logo and to change the corporate colors? Again all you need to do is make these changes on the Master Page and these changes will be reflected throughout your site.

The second important point is that since these pages are part of a SharePoint library they inherit all the SharePoint library features. The page model takes advantage of all underlying SharePoint support capabilities, including versioning, check-in and check-out, and workflows.

Site Structure and Page Model

Let’s do a quick review of what it means to have a Web site using this page model.

l Sites are a collection of Webs

Ø The Webs are arranged in a hierarchy

Ø Hierarchy controls navigation and security

l Each Web has a document library for Pages

l Page Layouts, Master Pages are stored in the root Web
Master Page Gallery

l CSS files stored in the root Web Style Library

In the previous module we learned how the site structure is a hierarchy of SharePoint Webs. We also learned that Webs are container objects that can contain libraries or other Webs and that each Web has a library called pages where the page items mentioned in the previous slide are stored. This represents the content of the site but what about the presentation?

All the elements that define how the content of your site will appear are stored in the root Web highlighted here in blue. These elements include Page Layouts, Master Pages, and CSS stylesheets which we’ll look at in greater detail in this module. These elements are stored in a Master Page Gallery which is a document library in the root site of the site collection and are shared across the Web site. The Master Page Gallery stores all the chrome master and page layouts used to control branding and authoring. This document library supports views, versioning, check in, check out, and workflows as does any other SharePoint list.

Together, this hierarchy of Webs with their libraries and the items in their libraries using the common SharePoint elements define the Web site and its Web pages.

Branding SharePoint 2007

Office SharePoint Server 2007 enables branding by separating content from display through the use of Master Pages, Pages Layouts and CSS styles. Branding is controlled in one place and applied top-down in your Web site and you can restrict authors to create pages that comply with your branding through the use of Page Layouts and control restrictions.

Master pages provide the look and feel and standard behavior that you want for all of the pages in your site. Page layouts contain field controls that allow content to be edited and rendered for display. They also reference a master page and host field controls that bind to fields on the master page list item. Together with content pages, they produce output that combines the layout of the master page with content from the content page.

Because Windows SharePoint Services is built on top of Microsoft ASP.NET 2.0, it supports master pages for defining elements that are common to all pages. You can specify all of the shared elements of your site in the master page or pages, and add content page-specific elements to content pages. Using master pages gives you a single-location ability for change. You can make design changes in one place and propagate the changes to all pages that use the master page.

CSS styles can be used to define and change the look and feel of items on the page.

Summary

l SharePoint separates content from display

l Master Pages provide the look and feel

Ø ASP.NET 2.0 Master Pages control look and feel of the Web site

l Page Layouts provide the template for rendering

Ø Reference a master page for global navigation and chrome

l CSS styles

Ø Alternate CSS setting allows for CSS overrides independent of master page used

Master Pages

Remember that in the page rendering process we looked at earlier, the Page layout executes controls that render the title, the body, the description from page fields in the page item, but the Page layout doesn’t full own the presentation of content. The Page Layout must also use a Master Page that defines the common shared look and feel across the site. We mentioned Master Pages earlier in the day and used some of the functionality of Master Pages especially in the Navigation module. Now we’re going to cover Master pages in greater depth, and we’ll look at the Page Layout template later in this module.

Master pages are a feature of ASP.NET 2.0. When a user requests a content page, it is merged with a master page to produce output that combines the layout of the master page with the content from the content page. All content pages share the same page structure—the global breadcrumb, site title area, top navigation, page title area, and left navigation bar. This shared page structure is contained in the master page called default.master, which is used by all content pages.

In addition to static text and controls that appear on all pages, a master page also includes one or more System.Web.UI.WebControls.ContentPlaceHolder controls, which define regions where replaceable content can appear. In turn, the replaceable content is defined in content pages.

Imagine, for example, that you want every page in an application to use the same layout along with a standard header and navigation menu. In that case, you can create one Master Page with the desired layout and base all the pages in the application on the Master Page. By creating a single Master Page, you avoid performing the work of duplicating the common content for each page. Also, if you decide to change the layout of all the pages in the future, you need to modify only the single Master Page.

You create a Master Page by creating a page with a .master extension. A Master Page can contain almost anything that you can include in a normal ASP.NET page. What makes a Master Page special is the fact that it can contain one or more <asp:ContentPlaceHolder> controls. The <asp:ContentPlaceHolder> controls indicate regions of replaceable content in the Master Page.

You can base any ASP.NET page on a master page template simply by adding a directive to the page (for example: <%@ Page Master=”SiteLayout.Master” %>). The ASP.NET page can then optionally override any of the <asp:ContentPlaceHolder> regions declared within the Master Page. At runtime a single merged page will then be sent down to calling browser clients.

Customizing a SharePoint Master Page

There are supported scenarios for customizing master pages:

Copy the default.master file that is installed with Windows SharePoint Services to another file and make your changes to your renamed file. This option is considered a Best Practice since you may want to use the default.master file later.
Edit the default.master page in Microsoft Office SharePoint Designer 2007 where you can edit master pages, view master pages, create content pages, and view content pages with the master pages marked as masters and read-only.
Follow the MSDN guidance:

· How to: Create a Minimal Master Page - http://msdn2.microsoft.com/en-us/library/aa660698.aspx

· Page Layouts and Master Pages: http://msdn2.microsoft.com/en-us/library/ms543497.aspx

· http://www.heathersolomon.com/blog/

When a new site is created, it uses the default master page that is located in the file system. If a master page is customized using Office SharePoint Designer, Windows SharePoint Services stores a modified version of the master page in the content database.

Page Layouts

l Page layouts provide the template for rendering

Ø Reference a master page for global navigation and chrome

Ø Can have many layouts per content type

l Define what can be authored in the page:

Ø Field controls

Ø Web Parts

Ø Web Part zones

l Define how much control the author has over page content’s look and feel

Ø Turning on restrictions on field controls

Ø Wrapping controls in CSS classes

As we said earlier the Page Layout selected for a content page calls the appropriate Master Page. Now we will discuss the Page Layout in greater detail.

A page layout is a template that is used in conjunction with a master page to control the look, feel, and content of a page. Each page layout has an associated content type that determines the kind of content that can be stored on pages based on that page layout. Microsoft Office SharePoint Server 2007 provides three default publishing content types: Page, Article Page, and Welcome Page.

Imagine, for example, that you have 1000 article pages with an image on the right and that Corporate Communications has decided the image should now appear on the left. In that case, you need to modify only the single Page Layout. You can modify the Page Layout with the desired layout and all the article pages with that layout will reflect the new layout standard.

All page layouts reference a master page that is based on the SPWeb.CustomMasterUrl of the SPWeb class. If multiple Master Pages are available, the page layout determines which Master Page is called for the particular page. All page layouts host controls called field controls that bind to fields on the master page list item. You can use the default controls or build custom ones. Field controls allow content to be edited and rendered for display, just as placeholder controls in MCMS 2002 do.

Page layouts can be used by all page instances that are based on that page layout. Page instances based on the same page layout in different sites can use different master pages.

Page layouts are stored in the Master Page and Page Layout Gallery, a document library that is created when you install Office SharePoint Server 2007. By default, Office SharePoint Server 2007 creates a master page gallery for every site; however, you can only create new pages with the page layouts stored in the master page gallery of the top-level site in the site collection.

As with any type of document stored in a SharePoint library, you can use versioning, check-in and check-out, workflow, and other features on page layouts. These features are available from within the master page gallery. The master page gallery is secured to limit the rights of most users, except those users with designer or higher permission rights.

CSS Styles

l Customized CSS only applies to current Web

l To apply to all Webs in Microsoft^® Office SharePoint^® Server 2007

Ø Make independent CSS file just with style overrides

Ø Reference it in custom.master and/or default.master (after CssLink control)

Ø Choose site setting to push down masters to all subwebs

Graphic Design Requirements

Consider what graphics and graphic design you require for your site:

· Will your site require banner images of specific sizes?

· Will your site require highly customized images that define the very look and feel of the site? For example, these may be curves that are positioned and lined up with other custom images via html to represent a corporate brand or look and feel.

· Do you have graphics development and creative site design skills required?

· Do you require high optimization of your images (to minimise total page download size) for internet /extranet site scenarios?

Sites that are highly visible (intranet home page) or sites that provide a specific service are good candidates for highly crafted User Interface design.

Examples of these are:

· Corporate

o Corporate Portal Theme

o Corporate Site Theme(s)

· Point Solution (Business Driver Sites)

o Library

o Search Centre

o Press Centre

o Research Centre

o Company Division

o Etc

Interaction Level

Some sites in your organisation may require a high degree of interactivity and as a result may require use of the following rich / interactive media:

· Video

o Video Streaming

o Web Casts

o Interactive Media Manager

· Audio

o Audio Streaming

o Pod Casts

· AJAX

· Silverlight

· Adobe Flash

· SoapBox / YouTube integration

· Virtual Earth / Google Maps

For each of the above, consider:

· Load on your environment

· Return on Investment (ROI) and Total Cost of Ownership (TCO)

· Level of complexity required to maintain and grow.

· Reliability of external services

· Maturity of technologies (against future potential of the same technology).

· Skill set required to develop.

· Skill set required that you need to retain to maintain and progress solution

Navigation

Exterior navigation refers to the navigation elements across a set of sites collections and sites. Examples include: Site and Page Navigation, Breadcrumbs.

Interior navigation refers to navigation elements placed within a site, such as the Table of Content Webpart, Content by Query Webpart, Links Webpart. This may take the form of aggregated links from sub sites to a list of links.

Exterior Navigation

In Office SharePoint Server 2007 the site structure is a hierarchy of SharePoint Webs which controls navigation. Webs are container objects that can contain other objects, such as lists, libraries or other Webs. The Webs are arranged in a hierarchy and this hierarchy controls the navigation and security. Each Web has a library for Pages which represent the content of the site.

Portals are a collection of Windows Server System Webs

The Webs are arranged in a hierarchy
Hierarchy controls navigation and security

Each Web has a document library for Pages
Page layouts are stored in the root web Master Page Gallery
CSS, XSLT are stored in the root web Style Library

The goal of navigation in Office SharePoint Server 2007 is to generate dynamic page navigation from the structure of the site. The hierarchy of sites and pages defined in the left-hand side of this slide defines the different levels as they appear to the user displayed here on the right. In the next module we’ll see how these are actually Master Page controls. Pages are dynamically added to navigation and static Authored links to external or internal resources can also be added.

In the example below you see some of the controls typically displayed on a page: a top navigation bar with a highlighted breadcrumb and a menu with fly outs. The goal of navigation is ease of use and transparency so when you create a new subsite in this hierarchy—for example under Investors—the new subsite will automatically appear on the page as part of the navigational structure. In this example, it appears in the fly out. Pages are also dynamically added. And you can display Authored links to any resource within your Internet or any rendered http:// link.

Behind the cover, Microsoft Office SharePoint Server 2007 takes advantage of Microsoft ASP.NET 2.0 pluggable navigation—the Site Map Provider model—to make it easy to build effective menus and navigation. Essentially the provider extracts the hierarchy from the site map and then data sources plug into the hierarchy at any level to display the navigation and controls.

You use a site map to describe the logical structure of your site. You can then manage page navigation by modifying the site map as pages are added or removed, instead of modifying hyperlinks in all of your Web pages. The ASP.NET controls display navigation menus on your Web pages and these navigation menus are based on the site map.

In Office SharePoint Server 2007, you can replace the default navigation provider with your own. You can also configure multiple navigation providers for a site. You can even configure your navigation provider to create a navigational structure targeted to audience type, so that you can provide different audiences with custom navigation.

Interior Navigation

Several controls for interior navigation:

For rolling up pages in a particular subsection of the site, SharePoint Server provides the Table of Contents control. This control allows authors to create and style a hierarchical view of pages.

· Provides a “site map” view of a site

· Uses data from the navigation sitemap provider

Content by Query

It is often useful to generate a list of links to a series of pages through the site, based on a fixed set of criteria. For example, it might be useful to display a list of the five most recently published press releases about a particular product on the overview page for that product. To accomplish this SharePoint Server provides the Content By Query control. This control allows users to easily define queries that return links to pages that match certain criteria and then style the results.

· Links to content based on a query

· For example, display latest 5 KB articles for SharePoint Server

Summary Links

For selecting links through the site, and from external sites, the Summary Links control enables you to create summaries that include a link, description, and an image, and to set a display style for the summary. Summary links can be organized into groups and sorted using drag and drop.

· Authored links to content

· Same visual styles as Content by Query

Web Parts in Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:41:00 GMT

Web Parts

When adding functionality to existing and new sites, it is important to be able to decide between “use Out of the Box”, buy 3^rd Party Web Parts, use Community Web Parts, or custom develop the webpart from scratch or by taking community Web Parts in house.

Overview

· Use and configure Out of the Box Web Parts à Realise value from existing investment.

· Buy 3^rd Party SharePoint Solutions depending on support model and code access/ functionality request availability.

· Use Community Web Parts with restrictions

· Develop your own Web Parts

Deciding between Third Party versus Custom Web Part development

· When deciding whether to buy a 3^rd Party web part or custom develop a Web Part , weigh up following criteria:

o cost of buying the webpart

o support model available

o Web Part provider company

§ Availability (Email only; telephonic; 24 hour?; on site)

§ Location

§ Time Zone

§ Can this company understand your native language?

§ Source Code License?

§ Feature Request framework in place: Can a customer request and pay for new functionality required for the Web Part?

o Complexity of the webpart

o Do you have access to the source code? (Even if under license)

o Keep in mind future changes you may require to the webpart when buying.

Deciding whether to use Community Web Parts

· As a rule of thumb, the answer should always be NO until explicit permission is given for each webpart by your change control governance board.

· Community Web Parts are awesome, but pose a risk to your environment that needs to be managed.

· There are a bunch of high value, FREE Web Parts available for download from sites such as CodePlex, and SharePoint blogs. Most of them provide the source code to allow you to take the Web Part in house.

· Don’t rule them out completely, always seek to reuse IP, rather than build complex functionality from scratch.

· Analyse performance, security, code of community webparts. Don’t simply trust that they will work.

· Test, test, test in test environment before releasing into your Production environment.

· Assess, assess, assess impact on performance in production

Third Party / Community developed Web Part Sources

Disclaimer:

1. This is not a comprehensive list of web parts available. It is intended to be a starting point that should be expanded and maintained as you learn about new web parts from 3^rd Parties and Community Sources.

2. It is not an endorsement of any particular product over another product in the market. It merely represents my subjective experience and exposure to these products. Therefore, you should always aim to perform a diligent search for Web Parts and their competing solutions.

Sites

Mark Kruger, MVP has a fantastic list of 3^rd Party Web Parts:

http://www.sharepointblogs.com/mkruger/archive/2007/06/26/free-sharepoint-web-parts-3rd-party.aspx Some of these were developed for WSS 2.0 and some for WSS 3.0. WSS 2.0 can still be used and deployed in WSS 3.0 however ensure you test and check that the functionality works in your environment.

Ian Morrish http://www.wssdemo.com/default.aspxThis is a fantastic site that has tons of demos for you to view and links to SharePoint resources on the web.

Bamboo Solutions: http://store.bamboosolutions.com/

CorasWorks: http://www.corasworks.net/Products/

CodePlex: http://www.CodePlex.Com CodePlex is Microsoft's open source project hosting web site. Start a new project, join an existing one, or download software created by the community.

SharePointPedia: http://www.SharePointPedia.Com This site contains links to tons of SharePoint resources, including web parts. SharePointPedia.com is a web site where people discover and share useful content about SharePoint and SharePoint related products and technologies.

Web Parts

SharePoint Forums Web Part: http://www.codeplex.com/SPFORUMS.
Community Kit for SharePoint : http://www.codeplex.com/CKS.
RSS FeedReader: http://www.codeplex.com/FeedReader
WCM Web Parts: http://www.codeplex.com/SPWCMWebParts
Navigation Web Parts: http://www.codeplex.com/sharepointnavigation

Develop your own Web Parts

Web Parts in Windows SharePoint Services provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.

The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.

Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.

Following are some ways in which you can use custom Web Parts:

· Creating custom properties you can display and modify in the user interface.

· Improving performance and scalability. A compiled custom Web Part runs faster than a script.

· Implementing proprietary code without disclosing the source code.

· Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.

· Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.

· Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.

· Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.

· Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.

· Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.

· Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.

Deciding whether to create ASP.NET Web Parts versus SharePoint Web Parts

When you are creating Web Parts for Windows SharePoint Services, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or the Windows SharePoint Services WebPart class.

(The Windows SharePoint Services WebPart class was available in Windows SharePoint Services 2.0, and was part of a Web Part infrastructure that was designed specifically for SharePoint sites.)

Now that Windows SharePoint Services fully supports the Microsoft ASP.NET 2.0 Web Part infrastructure, you should design Web Parts that inherit from the ASP.NET 2.0 System.Web.UI.WebControls.WebParts.WebPart base class whenever possible. Web Parts such as these are known as ASP.NET Web Parts, and can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable.

Note: If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.

For more information about creating ASP.NET Web Parts, see Web Parts Control Set Overview in the ASP.NET documentation.

When to Derive from the Windows SharePoint Services WebPart Class

In a very few cases, you may have to create Web Parts that support Windows SharePoint Services features that are not available in the ASP.NET Web Part infrastructure. In these cases, you can create a class that inherits from the Windows SharePoint Services WebPart base class. Web Parts such as these are known as SharePoint Web Parts and can only be used in SharePoint sites.

Note: The Windows SharePoint Services 3.0 Web Part functionality is essentially unchanged from Windows SharePoint Services 2.0.

Following is the list of features provided exclusively by the Windows SharePoint Services WebPart class:

· Cross page connections

· Connections between Web Parts that are outside of a Web Part zone

· Client-side connections (Web Part Page Services Component)

· A data caching infrastructure that allows caching to the content database

Another reason you may consider deriving from the SharePoint WebPart class is related to creating new versions of your Web Parts. If your original Web Part derived from the SharePoint WebPart class, and you want to upgrade instances of that Web Part to a new version, then the new version of the Web Part should also derive from the SharePoint WebPart class.

Features in Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:35:00 GMT

Features

Feature framework is an innovation to enhance modular provisioning. It works by grouping logical elements into scenario-driven “features”.

l Features can be add to and reused across site definitions

l New features can be activated in existing site to add functionality

l Features scoped at web, site ,web application and farm.

l Features need to be installed before they can be activated, via stsadm.exe or custom code using SharePoint API

l Once installed, a user can activate or deactivated feature in context of site or site collection

Features are composed of XML files and .aspx files

l XML in CAML

l Features have ID, name, scope

l Features are composed of elements

l Generate GUID using Visual Studio 2005

Feature Dependencies

Features can be designed with dependencies: Allows one feature to assume another feature is present Example: Feature B might depend on feature A.

l B should be written with activation dependency on A

l Activating B forces A to be activated as well

l Deactivating B results in deactivation of A

Features can be defined as hidden; this will hide the feature from users in administration pages, however it can still be activated via dependencies

Features and Site Definitions

Features add modularity to site definitions: Site definitions can include feature references, e.g. Lists, document libraries, content types, etc.

Activating Features via the UI

Feature elements can add commands to WSS 3.0 UI:

l Extensible to site settings, action actions, menus, ECB, etc.

l Performed using SiteActions menu elements with Url Action

l ECB menu associated by list type, content type or file type

Feature Site Template Associations a.k.a. Feature Stapling

l Enables you to include a specific feature as part of a site definition when you provision sites through the site definition

l Preserves original out of the box definitions

l Keeps customer environment in a supported state

l Makes it easier to manage customizations in customer environments

l Reduces development and deployment time

Examples of where SharePoint can be extended using Features (based on scope):

Farm Elements

l Item Custom Actions

l Site Settings Links

l Admin Custom Actions

Web Application elements

l Item Custom Actions

l Site Settings Links

l Admin Custom Actions

Site Elements

l Site Settings Links

l Site Web Part Definitions

l Workflow Definitions

l Site Content types

l Site columns

l Files [provisioned to root web]

l List Instances [provisioned to rootweb]

Web Elements

l List Definitions + Forms + Views

l List Instances

l List Item Events

l Item Custom Actions

l Web Admin Custom Actions

l Files

Field Definitions in SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:30:00 GMT

Fields

A column template is a collection of well-known instances of particular fields—in other words, a shared field definition. A shared field includes settings for that field, such as the set of choices for a choice field, or whether rich text is supported for a text field.

An example of a shared field would be "Specification Status," which has standard choices such as "One Page," "Draft," "Reviewed," and "Inspected." Each team in a deployment can reuse this custom property definition on their site.

Shared fields are a provisioning concept referred to by content types, such that if you provision a site collection with two separate content types that use the same shared field, the provisioning script for those content types instantiates the exact same field, and each field instance shares the same unique identifier.

Possible scopes:

· Farm: No

· Web Application: No

· Site Collection: Yes

· Web Site: No

For general information about column templates and how they function within Windows SharePoint Services, see Introduction to Columns. For information about the file format used in column templates, see Content Type and Column Template Definition Files.

· Fields: http://msdn2.microsoft.com/en-us/library/ms426306.aspx

· Introduction to Columns - http://msdn2.microsoft.com/en-us/library/ms450825.aspx

· Column Definition Schema Overview - http://msdn2.microsoft.com/en-us/library/ms459922.aspx

· Field and Field References - http://msdn2.microsoft.com/en-us/library/aa543680.aspx

· FldTypes.xml - http://msdn2.microsoft.com/en-us/library/ms469928.aspx

· Updating Site Columns - http://msdn2.microsoft.com/en-us/library/ms466937.aspx

· SharePoint 2007 Features – Creating Site Columns and Content Types - http://sharethispoint.com/archive/2006/07/17/11.aspx

List Definitions versus List Templates and deciding on the correct customization approach

Brian Wilson — Sun, 13 Jul 2008 21:18:00 GMT

List Definitions

A list template Feature includes a Schema.xml file that serves as the base file for a list definition. The List element is the root element of a Schema.xml file, which contains default view definitions, definitions for special fields used in the list, the toolbar definition for list views, content type declarations, and other metadata for the list.

A list definition includes a Feature.xml Files file, an element manifest file (see List Template Files), and a Schema.xml file within a Feature folder (\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES). For an example that shows how to create a custom list definition, see how to: Create a Custom List Definition: http://msdn2.microsoft.com/en-us/library/ms466023.aspx

Lists can be created or modified programmatically through the object model (for example, members of the SPList and SPListCollection classes), through the Lists Web service (methods of the Lists class), and through Remote Procedure Call (RPC) protocol (see Microsoft Windows SharePoint Services RPC Methods).

Introduction to Lists: http://office.microsoft.com/en-us/sharepointtechnology/HA100242741033.aspx?pid=CH101787241033

List Schema: http://msdn2.microsoft.com/en-us/library/aa543477.aspx

Major Schema Definition Files: http://msdn2.microsoft.com/en-us/library/ms479188.aspx

List Templates

A list template is something the end user can create by using the web interface to configure the list. This list can then be saved as a list template. This list template is stored as an *.STP file in the list templates gallery of the Site Collection. This *.STP file is stored in the content database the Site Collection resides.

This file contains all the customizations made to the original List Definition, such as CAML and XML that describes the lists. The customizations require the same list definition to be installed on the server that was used to configure the list templates.

It is not as performant as a pure list definition as list definitions are cached on start of IIS on the web front ends while list templates are stored in the Content Database, They need to be fetched from the content database and merged with the list definition code at runtime to render the list.

Deciding Between List Definitions and List Templates

Custom list definitions hold the following advantages over list templates:

· Data is stored directly on the Web servers, so performance is typically better.

· A higher level of list customization is possible through direct editing of a Schema.xml file.

· Certain kinds of customization to lists require use of site and list definitions.

List definition disadvantages include the following:

· Customization of list definition requires more effort than configuring list templates.

· Editing a list definition after it has been deployed is difficult.

· Doing anything other than adding code can break existing sites.

· Customizing list definitions requires access to the file system of the front-end Web server.

List templates hold the following advantages over customization of list definitions:

· List templates are easy to create.

· Almost anything that can be done in the user interface can be preserved in the template.

· List templates can be modified without affecting existing sites that have been created from the templates.

· List templates are easy to deploy.

List template disadvantages include the following:

· List templates are not created in a development environment.

· List templates are less efficient in large-scale environments.

· If the List definition on which the list template is based does not exist on the front-end server or servers, the list template does not work.

Site Definitions versus Site Templates and deciding on the correct customization approach

Brian Wilson — Sun, 13 Jul 2008 21:02:00 GMT

Site Definitions

l A site definition is the core definition of what a site is in SharePoint.

l A site definition is installed on file system of web front ends, located at ..\12\Template\SiteTemplates. This directory is language-neutral.

l A site definition consists of .aspx pages and .xml files with Collaborative Application Mark-up Language (CAML).

l A major benefit is that the Page and List definition is read locally from the file system, not from Content Database.

l A site definition Page and List definition are cached at IIS process startup

l Customizations made to site definition are stored in content database, not on the file system. This can be performed via SharePoint Designer, or when custom site templates are saved.

l are developer created

l Localization: WSS 3.0 supports full site template localization (based on ASP.Net 2.0 via XML files and .ASPX files pulling strings from RESX files. Therefore solutions can be shipped “language packs” of resource files.

l “Global Template” defines commonality across site definitions; it gets called before any other template. It works by injecting common provisioning content into all new sites. ONET.XML file defines base types, galleries, mobile redirects

· Site Definitions and Configurations - http://msdn2.microsoft.com/en-us/library/aa978512.aspx

· CAML - http://msdn2.microsoft.com/en-us/library/ms462365.aspx

Site Template

A site template (*.stp file) is created through the user interface or through implementation of the object model. It is a package containing a set of differences and changes from a base site definition.

The site template package is stored as a CAB-based file that can be downloaded or uploaded to site collections by users with the appropriate rights. As before, site templates offer a measure of portability to SharePoint Applications.

It is not as performant as a pure site definition as site definitions are cached on start of IIS on the web front ends while site templates are stored and hence need to be fetched from the content database and merged with the site definition code at runtime to render the site.

Also note that if you plan to transfer a site template to separate farm, that the farms have the same versions installed of SharePoint installed. (hotfixes,etc.) This is due to the dependence site templates have on the original base site definition they were created from.

Deciding Between Site Definitions and Custom Site Templates

See : http://msdn2.microsoft.com/en-us/library/aa979683.aspx

When choosing whether to create a site template or a site definition, first consider the following issues:

· Are the changes you need to make simple or complex? If, for example, you need to make only minor changes in the look of certain pages and add a few fields in particular lists, you should create a custom site template. However, if you need to create new content types, add new Web Part definitions, and significantly restructure sites, you should create a custom site definition.

· Can you deploy changes to the front-end Web server? If you do not have access to the file system of the computers running Windows SharePoint Services, you have no choice but to create a custom site template.

Custom site definitions hold the following advantages over custom templates:

· Data is stored directly on the Web servers, so performance is typically better.

· A higher level of list customization is possible through direct editing of a Schema.xml file.

· Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu.

Site definition disadvantages include the following:

· Customization of site definition requires more effort than creating custom templates.

· Editing a site definition after it has been deployed is difficult.

· Doing anything other than adding code can break existing sites.

· Users cannot apply a SharePoint theme through a site definition.

· Users cannot create two lists of the same type with different default content.

· Customizing site definitions requires access to the file system of the front-end Web server.

Custom templates hold the following advantages over customization of site definitions:

· Custom templates are easy to create.

· Almost anything that can be done in the user interface can be preserved in the template.

· Custom templates can be modified without affecting existing sites that have been created from the templates.

· Custom templates are easy to deploy.

Custom template disadvantages include the following:

· Custom templates are not created in a development environment.

· Custom templates are less efficient in large-scale environments.

· If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template does not work.