In WSS 3.0, if you want to create a WSS site, you must run an administrative tool to extend the WSS functionality to an IIS web site.

This process is similar in WSS 2.0, with the main difference really in the terms used to describe how you extend functionality to one or more IIS web sites. In WSS 2.0, this was referred to as creating a “virtual server,” which was essentially an IIS web site that had WSS 2.0 functionality. In WSS 3.0, they are no longer referred to as “virtual servers”; they are now referred to as “web applications.” This is a minor difference, but helpful in determining which version of WSS someone is referring to with respect to WSS functionality.

Another key difference between WSS 2.0 and WSS 3.0 is that WSS 3.0 is built on top of ASP.NET 2.0, whereas WSS 2.0 was build on top of ASP.NET 1.1. ASP.NET 2.0 provides significant improvements over ASP.NET 1.1. For example, WSS 2.0 tied into IIS 6.0 and ASP.NET 1.1 using an ISAPI filter DLL. The problem with this was that requests were routed directly to WSS without first being initialized with ASP.NET context. This could be problematic in certain situations where the developer wanted to process and handle requests with custom code before WSS processed a request. WSS 3.0 solved this problem by making all HTTP requests enter the ASP.NET 2.0 runtime environment. As a result, the requests are fully initialized with ASP.NET context before they are forwarded to the WSS 3.0-specific code.

The WSS 3.0 team accomplished this by removing the ISAPI filter and adding an HttpModule and an HttpHandler. HttpModule and HttpHandler are registered with ASP.NET 2.0 using entries in a web.config file. As a result, all incoming HTTP requests are mapped to the ASP.NET runtime, regardless of file type. After ASP.NET 2.0 processes the request and adds context, the requests are forwarded to WSS 3.0 to be processed.

Another interesting change is how WSS 3.0 handles the parsing and compiling of .aspx pages. ASP.NET 2.0 has the ability to retrieve .aspx pages from any location. In the case of WSS 3.0, that is typically a SQL Server database. This offers WSS 3.0 a significant improvement over WSS 2.0 in terms of page parsing. This is accomplished by using a virtual path provider, called SPVirtualPathProvider, which is a pluggable component type. Essentially, an .aspx page is retrieved by the virtual path provider and then is passed to ASP.NET 2.0. ASP.NET 2.0 performs the required parsing and compilation and then passes the .aspx page off to SharePoint, which controls how the .aspx page is parsed and compiled. The SharePoint component used to compile and parse the .aspx page is the PageParserFilter. WSS 2.0 handled this much differently. With ASP.NET 1.1, .aspx pages could be parsed and compiled only if they resided on the local filesystem. This was a significant limitation when WSS inherently used SQL Server as the location from which it retrieved .aspx pages.

In WSS 2.0, WSS and SharePoint developers had a tough time creating a consistent look and feel throughout an entire site due to the limitations in ASP.NET 1.1. As a result, developers would spend many tedious hours cloning and recreating HTML from site to site. With WSS 3.0 and ASP.NET 2.0, this has all changed for the better. ASP.NET 2.0 introduced a new feature called the master page. If you have ever worked with products like Dreamweaver (which is now an Adobe product), you know that the concept of a master page is a beloved feature for developers. Developers could create a master page, where they put all the look and feel that drives the site. When that developer wanted to change the look of the site, he needed only to change the master page and save the change, and the tool would recurse through all the associated pages and make the appropriate changes to match that master page. ASP.NET 2.0 introduced master pages to provide developers with this type of functionality, but with a much more elegant solution that did not require a tool to recurse through all the pages of a site. In ASP.NET 2.0, the pages that link to a master page, known as content pages, take on the shared layout of the master page and then extend the master page by inserting customized content in the named placeholders.

WSS 3.0 was designed from the ground up to leverage ASP.NET 2.0 master pages. When a WSS 3.0 site is created or provisioned, a Master Page Gallery catalog is created that contains a default.master master page. This master page defines to share layout for the home page (default.aspx) and the form pages associated with lists and document libraries, such as AllItems.aspx. This master page includes navigation controls, menus, and visual aesthetics. Like most master pages, this master page contains placeholders for different custom content, such as PlaceHolderPageTitle and PlaceHolderMain. Making changes to a content page is as easy as changing the content contained within these placeholders:

	<%@ Page language="VB" MasterPageFile="~masterurl/ default.master" %>
	<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
	<h2>Check out my simple customization with WSS 3.0</h2>
	<h3>I can't believe how easy this is to do compared to WSS 2.0</asp:Content>

The content page definition simply places HTML content inside PlaceHolderMain, but it produces the typical page layout with site icons, menus, and navigation bars. The amount of work associated with changing and branding the look for a site has been drastically reduced. You can also edit the standard set of placeholders defined in default.master. This allows the developer to replace WSS elements such as menus and navigation bars with her own ASP.NET controls. You can even use new AJAX-type controls provided in ASP.NET 2.0 for pages both at the scope of a site and at a site collection.

In WSS 3.0, master pages and content pages are stored and loaded in the same way as page templates and page customizations (discussed in the next section, "Page Templates”). Master pages and content pages can be stored both on the filesystem and in SQL Server, depending on whether they are uncustomized or customized. Users can change these master pages and content pages using SharePoint Designer. As a result, the customized master page or content page will be stored in SQL Server. Both WSS and SharePoint Designer provide simple menu commands that allow users to discard customizations and revert to the original master page or content page (Figure 2-3).

A great feature of both WSS 2.0 and 3.0 is the ability to store an .aspx page template on the local filesystem of a frontend web server, which can be used across many different web sites. This template then can be used thousands of times by hundreds of web sites, while requiring the .aspx template to be loaded only once into memory. The performance benefits here are tremendous.

When a user wanted to customize or modify the .aspx template in WSS 2.0, the modifications and customized version of the template would then be stored in SQL Server. In reality, this feature has not changed from WSS 2.0 to WSS 3.0; the only difference is the nomenclature. In WSS 2.0, this was referred to as ghosting and unghosting. The ghosted .aspx page was a template that had not been modified. As soon as the developer made modifications to the template, and the template transformed into a customized template stored in SQL Server, that template or page was then referred to as “unghosted.” In WSS 3.0, the “ghosted page” is now referred to as an uncustomized page, and the “unghosted page” is now referred to as a customized page. This is a simple change, but relevant enough to bring up in this context.

There has also been a change in the tools used to modify pages or templates. Previously, Microsoft Office FrontPage 2003 was used to modify .aspx pages for use in WSS 2.0. Microsoft has recently released Office SharePoint Designer 2007, which is essentially the most recent release of FrontPage. The target audience for this new tool will still be WSS developers. SharePoint Designer is a great WYSIWYG editing tool with some powerful features for editing HTML and styles, and new features for creating lists and document libraries. Microsoft has also added a wizard for creating custom workflows in a WSS site. The name change from Microsoft Office FrontPage 2003 to Office SharePoint Designer 2007 is significant for a product that has been around for nearly 10 years. FrontPage has been replaced by a new product called Microsoft Expressions Web, which is a tool targeted at pure web developers.

Figure 2-3. Microsoft Office SharePoint designer editing a master page

WSS 2.0 supported event handlers only in document libraries, not in lists. It also supported only asynchronous events, which are events that fire after a user action is committed to the SQL Server Database. The big problem here was that this limitation did not provide a way for developers to cancel a user’s action inside the event handler.

As a result, code could be executed without any way for the developer to control execution. These limitations have been resolved with WSS 3.0.

In WSS 3.0, synchronous event support has been added. This feature allows developers to cancel user actions when an event is fired, for example, when a user initiates an action that is not allowed. Asynchronous events are still supported, but synchronous events represent a new feature that gives more control to the developers. Also, event handlers are now supported in both document libraries and lists.

WSS 3.0 provides developers with the ability to write an event handler by creating a class that inherits from a WSS 3.0 receiver class. The developer needs only to override the methods in order to handle events. A developer can also bind an event handler to lists or document libraries, which is done by creating code that extends the object model. They can also define an event receiver in a WSS 3.0 feature. (WSS 3.0 features are discussed later in this chapter.) The WSS 3.0 receiver classes use overridable methods that have different naming conventions for synchronous and asynchronous events. Synchronous events use method names such as PageUpdating, whereas asynchronous events use method names such as PageUpdated. As mentioned previously, synchronous events can be cancelled, but asynchronous events cannot.

As also mentioned previously, events are supported on both lists items and document libraries. There are some new features you should be aware of in this area. Developers now have the ability to fire events when a user changes the definition for a list. For example, this gives the developer the ability to cancel a user’s action to rename, move, or delete columns in a custom list. This is a very powerful feature for developers looking to control the look and feel of their custom lists or site collections.

Site definitions—a feature of both WSS 2.0 and WSS 3.0—provide developers with a great amount of control and reusability. A site definition is a directory on the frontend web server containing XML files and .aspx page templates that define a blueprint for the site. The site definition includes list schemas as well as page layouts. Collaborative Application Markup Language (CAML) is the XML-based language that is used inside site definition files.

If you have ever worked with WSS 2.0 site definitions, you know there are a few issues:

Fortunately, WSS 3.0 has provided solutions to all of these limitations and headaches.

The first a new enhancement to WSS 3.0 is features, which are similar to site definitions. They contain CAML-based XML files and page templates. The difference is that features allow a more modular approach to evolving or updating running WSS or MOSS sites. Features allow developers to define something as small as a single site element, such as a new menu, and then easily roll that feature out to any WSS 3.0 or MOSS site. The ease of use is provided through the flexibility of deployment. As a developer, you can deploy a feature using the WSS user interface or the command line, or even using custom code written using the WSS 3.0 object model. Also, features do not have to be defined within the content of a site definition.

The deployment headache also has been removed. With WSS 3.0, a new deployment mechanism called a solution was introduced. A solution is similar to a Web Part package because it is an aggregate .cab file containing XML instructions and files that must be deployed to frontend web servers. This is much easier to manage. Solutions support the deployments of features and site definitions, as well as event handler and workflow assemblies. Solutions are very easy to deploy. The developer simply needs to copy the solution .cab file into the configuration database and then run a command to deploy the solution. The WSS 3.0 timer job handles the push of the solution .cab file out to each frontend web server and then installs it.

The last milestone for this group of features is localization support. Localization is a core component to ASP.NET 2.0. WSS 3.0 takes full advantage of this ability and extends it to localize site definitions using .resx files. The following example shows how you would use standard ASP.NET 2.0 syntax to localize content for a WSS 3.0 site:

	<%$Resources:AdventureWorks,MyString%>

If you have worked with WSS 2.0, you know only too well that authentication is based on Windows accounts and their associated Security IDs (SIDs). Essentially, Active Directory is the foundation for authenticating users. For companies looking to create WSS 2.0 intranets or SharePoint Portal Server 2003 intranets, this was not a problem. You already have users in Active Directory, so employing it as your authentication tool is not a hassle or an inconvenience.

However, this is not the case when you are looking to deploy your WSS 2.0 site as an extranet to users who are not already maintained in Active Directory. This tight coupling to Active Directory forced organizations to maintain accounts for outside vendors and customers, which can present security risks and maintenance headaches for your IT Support team.

This limitation has been resolved by building WSS 3.0 on top of ASP.NET 2.0. ASP.NET 2.0 introduced a new feature that has greatly eased the maintenance and implementation headache associated with enabling forms authentication in web sites. ASP.NET 2.0 has a forms authentication provider that allows developers to maintain user accounts in a SQL Server database or some other identity repository, such as LDAP (Lightweight Directory Access Protocol) data sources. This feature provides WSS 3.0 with support for the same capabilities that are available in ASP.NET 2.0. The forms authentication provider allows easy support for creating and maintaining user accounts, and it also allows users to change and reset their passwords. Being able to change your password without calling the IT Support team has a huge maintenance and usability benefit.

Custom Web Parts have always been a powerful and compelling feature for WSS developers. However, the amount of effort associated with creating WSS 2.0 Web Part pages was significant. Microsoft recognized this and has provided a new model for developing WSS Web Part pages without losing backward compatibility with WSS 2.0 Web Part pages. It was a very important design goal for Microsoft to support both patterns of Web Part development. This was accomplished by building WSS 3.0 support for Web Parts on top of the ASP.NET Web Part infrastructure. Support for WSS 2.0-type Web Parts was accomplished by changing the Microsoft.SharePoint.dll so the older Web Parts would be compatible with the WSS 3.0 environment.

Now you have the ability to create WSS 3.0 Web Parts either based on ASP.NET 2.0 or in the WSS style. In order to create WSS-style Web Parts, you must have a dependency on the Microsoft.SharePoint.dll and you must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. This is the same way Web Parts were created in WSS 2.0, so not much has changed in that respect.

The new way of creating WSS 3.0 Web Parts based on ASP.NET 2.0 is different from the WSS-style. In order to create ASP.NET-style Web Parts, you have a dependency on System.Web.dll and inherit from a base class named WebPart in the System.Web.UI.WebControls.WebParts namespace.

To create an ASP.NET-style Web Part, you must create an .aspx page that contains only one instance of the WebPartManager control. Then, you add one or more WebPartZone controls. The WebPartManager control is responsible for serializing, storing, and retrieving Web Part-related data from tables in the ASP.NET services database. The resulting .aspx page can contain editor and catalog parts that allow the user to customize and personalize content as well as add new Web Parts into zones. Best of all, WSS 3.0 does the heavy lifting associated with adding catalog and editor parts into the page; the developer no longer needs to do this explicitly. This is different from the WWS-style Web Part creation process.

The WSS 3.0 Web Part infrastructure is built on SPWebPartManager, which is a control that derives from the ASP.NET 2.0 WebPartManager control. In order to create a WSS-style Web Part page, you need to do two things. First, create logic that interacts with the WebPartManager control, which will allow the Web Part to manage the display mode. Second, add editor and catalog parts with the HTML layout to handle them. This is different from creating Web Part pages for WSS 3.0 sites. With WSS 3.0 sites, the .aspx must inherit from the WebPartPage class defined in the Microsoft.SharePoint.WebPartPages namespace. This is a huge timesaver because WSS 3.0 handles all the work of dealing with the display mode, adding editor and catalog parts, and adding the HTML layout needed to accommodate the parts. This is another powerful feature for WSS developers.

You will typically use the WebPartZone control in content pages, rather than templates. The .aspx page would typically link to default.master. The difference you should note is that the .aspx inherits from the WebPartPage base class (Figure 2-4).

Figure 2-4. Different controls contained in a WSS-style Web Part page

The preferred way to create Web Parts for WSS 3.0 sites is to create the ASP.NETstyle Web Parts. As discussed before, this means inheriting from the WebPart base class in the System.Web.UI.WebControls.WebParts namespace and overriding the RenderContents method.

WSS 2.0 introduced some powerful features for document libraries, such as versioning, events, and folders. These features were not extended to lists, but fortunately this long-awaited missing feature has been introduced with WSS 3.0. Now lists support the same features around versioning, events, and folders. WSS 3.0 went one step further and introduced an exciting new feature that bloggers and blog readers have been familiar with for some time: automatic RSS feeds. Automatic RSS feeds allow users who are interested in data in lists and document libraries to subscribe to automatic feeds from those sources.

Another interesting feature that was overlooked in WSS 2.0 but is now provided in WSS 3.0 is column indexing. Column indexing alleviates some of the performance issues related to document libraries and lists in WSS 2.0. In WSS 3.0, you now can add an index to a column in a list or document library. This is not a physical index in SQL server; this index is created in WSS 3.0 with a table that holds the integer ID of the document or list item and the value of the indexed column. This improves performance because WSS 3.0 uses the table to more quickly return data from views. The speed increase is even more apparent when you are accessing data in a view that is based on a filter driven by the indexed column.

Yet another new content storage feature of WSS 3.0 is extensible field types, which create the potential for more granular control over field rendering and validation. Now the developer can create an extensible field type in C# or Visual Basic, just like you would in ASP.NET 2.0 applications. The caveat is that you need to inherit from one of the built-in SharePoint field types, such as SPFieldNumber or SPFieldText. With this feature you have the freedom to add all your favorite web controls to your WSS 3.0 or MOSS 2007 site in order to control initialization and validation.

Another innovative new feature of WSS 3.0 is custom site columns. The custom site column allows a developer to create a definition for a site column and then apply that site column to many lists within a SharePoint site. In WSS 2.0, you could define a custom site column only for a specific document library. This was limiting because you had to recreate the site column over and over again in each list or document library.

The backbone of the new custom site column feature is content types, a new storage mechanism. A content type is a WSS 3.0 type that allows developers to define the shape and behavior for an item in a list or document that resides in a document library. Essentially, developers can define multiple content types that apply to a specific list. For example, say you created a content type that had specific columns and its own document template, and then you create a second content type that has a completely different set of columns and events, as well as a new document template. You would be able to have both those content types in the same list or document library. This feature allows developers to deal with very complex heterogeneous types of content in lists and document libraries.

The workflow features in the WinFX runtime components are very exciting. These were released recently as the .NET Framework 3.0, in concert with the launch of Windows Vista. The renaming of WinFX to the .NET Framework 3.0 has been a bit confusing for most developers who are used to the .NET Framework 1.1 and 2.0, which each contained new compilers, libraries, and common language runtimes. Essentially, the .NET Framework 3.0 is an add-in set of new libraries that support the Windows Workflow Foundation (WWF), Windows Presentation Foundation (WPF), and Windows Communications Foundation (WCF). The WWF within the .NET Framework 3.0 includes an engine, pluggable components for persisting workflow state, and a Visual Studio 2005 designer. The designer makes it easy to create custom workflows by dragging and dropping components onto a workflow design surface.

Similar to WSS 3.0 building on ASP.NET 2.0, it also builds on top of the WWF. WWF gives WSS 3.0 the structure for attaching business logic to list items and documents. WSS 3.0 extends the basic workflow model in WWF by associating a task list and a history list with each workflow. This adds accountability to workflows that are human-oriented. A perfect example of this is a content management web site. In most enterprise content management systems, you have a workflow of approval for content that is to be published live to the Internet. Approval procedures limit a company’s exposure to erroneous content and malicious behavior. The same approach to workflow can be applied within WSS 3.0.

WSS 3.0 and MOSS 2007 both have basic workflows installed and ready to use. WSS 3.0 has some basic routing workflows, and MOSS 2007 has some more complex workflows similar to what is described in the content management example. However, the real power lies in the developers’ abilities to create custom workflows.