Web Part Infrastructure in Windows SharePoint Services

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Web Parts in Windows SharePoint Services 3.0 are based on the Microsoft ASP.NET 2.0 Web Part infrastructure. To create Web Parts for applications targeting Windows SharePoint Services, you should build custom Web Parts on top of the ASP.NET Web Part infrastructure. However, 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. For more information, see "When to Derive from the Windows SharePoint Services Class" in this topic.

Web Part Inheritance Model in Windows SharePoint Services

The Windows SharePoint Services 3.0WebPart class has been rebased to inherit from the Microsoft ASP.NET 2.0 WebPart class, providing a compatibility layer to ensure that Web Parts written for Windows SharePoint Services 2.0 work in Windows SharePoint Services 3.0 without modification. It exists primarily for the purpose of backward compatibility, and secondarily, to provide a small set of features that are not available in the ASP.NET WebPart class.

The following diagram demonstrates the inheritance hierarchy for the Windows SharePoint ServicesWebPart class.

Core Controls for Web Part Pages

The following section describes core controls for Web Part Pages for both SharePoint-based Web Parts and ASP.NET 2.0 Web Parts.

SharePoint-based Web Parts

The Windows SharePoint Services 3.0 Web Part infrastructure uses many of the controls in the ASP.NET 2.0 Web Part control set, as well as introduces several of its own controls that inherit from base classes supplied by the ASP.NET 2.0 Web Parts control set.

For example, Web Part Pages for a Windows SharePoint Services site do not use the standard ASP.NET WebPartManager. Instead, they use the Windows SharePoint Services-specific SPWebPartManager that inherits from the ASP.NET WebPartManager. The following figure shows the WebPartManager class inheritance.

Similarly, Web Part Pages for a Windows SharePoint Services site also use Windows SharePoint Services-specific WebPartZone that inherits from the ASP.NET WebPartZone.

ASP.NET Web Parts

The ASP.NET Web Part infrastructure is based on a WebPartManager class that manages the lifetime of Web Part instances at run time.

Each ASP.NET page that uses Web Part controls must contain:

• Exactly one WebPartManager object that tracks which Web Parts have been added to each particular zone, and stores and retrieves data about how each Web Part has been customized and personalized.

• One or more WebPartZone objects, into which Web Parts are placed.

To run Web Parts in an ASP.NET 2.0 application, you must create an .aspx page that contains exactly one instance of the WebPartManager control and one or more WebPartZone controls. The WebPartManager is responsible for serializing Web Part-related data as well as storing and retrieving it from the services database.

The .aspx page serving as a Web Part Page can contain editor parts that allow users to customize and personalize persistent Web Part properties. Web Part Pages can also contain catalog parts that let users add new Web Parts into zones. Windows SharePoint Services 3.0 does the work to add the catalog and editor parts for you, so that you do not need to explicitly do this in a Web page designer. The following figure shows the WebPartZone class inheritance.

The SPWebPartManager and WebPartZone controls manage the serialization of data associated with Web Parts into the appropriate Windows SharePoint Services content database. To be able to persist data, your ASP.NET Web Parts must be placed on a page with these two controls.

Because these Windows SharePoint Services-specific controls are required on pages that contain Web Parts, you cannot simply copy your ASP.NET page into a Windows SharePoint Services site. To move ASP .NET Web Parts from an ASP.NET application to a Windows SharePoint Services application, you should export them from ASP .NET and import them into a Windows SharePoint Services site.

Differences in Web Part Behavior between Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0

The Windows SharePoint Services team has gone to great lengths to ensure that your Windows SharePoint Services 2.0 Web Parts work seamlessly in Windows SharePoint Services 3.0. There are a small number of cases, however, in which your Windows SharePoint Services 2.0 Web Parts may behave differently. These include:

• In Windows SharePoint Services 2.0, Web Parts were managed by zones; however, in Windows SharePoint Services 3.0, Web Parts are managed by the SPWebPartManager. If you use a Web Part's Parent property, you get a reference to SPWebPartManager rather than a reference to the containing WebPartZone.

• In Windows SharePoint Services 2.0, both provider and consumer Web Parts can have multiple connections. In Windows SharePoint Services 3.0, the provider part can have multiple connections but the consumer part can have only one connection (same as that of ASP.NET 2.0 Web Part controls). You can replicate Windows SharePoint Services 2.0 behavior, however, by specifying UnlimitedConnections on the consumer Web Part.

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 ServicesWebPart base class. Web Parts such as these are known as SharePoint-based Web Parts and can only be used in SharePoint sites.

Following is the list of features provided exclusively by the Windows SharePoint ServicesWebPart 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 WebPart class is related to creating new versions of your Web Parts. If your original Web Part derived from the 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.

See Also

Concepts

Web Parts Overview

Developing Web Parts in Windows SharePoint Services

Other Resources

N:Microsoft.SharePoint.WebPartPages

ASP .NET Web Parts Control Set Overview

Discover Significant Developer Improvements in SharePoint Services