Web Parts in Windows SharePoint Services
3.0 |
|
One of the most popular ways for developers
to extend Windows SharePoint Services 2.0 sites has been to create
custom Web Parts. Web Parts are great because they add the extra
dimensions of user customization and personalization. As a
consequence, many teams at Microsoft and third-party companies alike
have built custom Windows SharePoint Services 2.0 solutions using
Web Parts.
Because
of the popularity of Web Parts in Windows SharePoint Services 2.0,
Microsoft decided to add support for custom Web Part development to
ASP.NET 2.0. This strategy to reach a wider audience of developers
was accomplished by creating a new Web Part infrastructure for
ASP.NET 2.0 that is similar yet distinct from the Web Part
infrastructure created for Windows SharePoint Services 2.0.
Consequently, there
are now two different styles of Web Parts. The older WSS-style Web
Parts depend on Microsoft.SharePoint.dll and must inherit from the
WebPart base class defined by the Windows SharePoint Services 2.0
teams in the Microsoft.SharePoint.Web- PartPages namespace. The
newer ASP-style Web Parts depend on System.Web.dll and must inherit
from a different base class also named WebPart defined by the
ASP.NET 2.0 team in the System.Web.UI.WebControls.WebParts
namespace.
It is
an important design goal for Windows SharePoint Services 3.0 to run
both the older WSS-style Web Parts as well as the newer ASP-style
Web Parts. This has been accomplished by building the Windows
SharePoint Services 3.0 support for Web Parts on top of the ASP.NET
Web Part infrastructure, and then making changes to
Microsoft.SharePoint.dll so that WSS-style Web Parts written for the
Windows SharePoint Services 2.0 environment would be forwardly
compatible with the Windows SharePoint Services 3.0 run-time
environment. |
|
To explain how Web Parts are loaded and run
in Windows SharePoint Services 3.0, this section discusses how the
Windows SharePoint Services 3.0 architecture was redesigned to layer
on top of the ASP.NET 2.0 Web Part infrastructure. First, I will
cover how Web Part Pages are laid out in Windows SharePoint Services
3.0, and then I get into the details of how to develop custom Web
Parts for a Windows SharePoint Services 3.0 environment.
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 control is responsible for
serializing Web Part–related data as well as storing and retrieving
it from the tables in the ASP.NET services database.
The .aspx page serving
as a Web Part Page can also contain Editor Parts, which allow users
to customize and personalize persistent Web Part properties. Web
Part Pages can also contain Catalog Parts, which allow users to add
new Web Parts to zones.
The Web Part infrastructure of Windows
SharePoint Services 3.0 is built on a control named SPWebPartManager
that is derived from the ASP.NET 2.0 WebPartManager control. The
SPWebPartManager control overrides the standard behavior of the
WebPartManager control to persist Web Part data inside the Windows
SharePoint Services content database instead of the ASP.NET services
database. In most cases, you don’t have to worry about dealing
directly with the SPWebPartManager control because the one and only
required instance is already defined in the standard default.master
page. When you create a content page that inherits from
default.master, the SPWebPartManager control is already there.
The other controls that appear on a typical
Windows SharePoint Services 3.0 Web Part Page are shown in Figure
1-4 on the next page and include Web Part zones, Editor Parts, and
Catalog Parts. Note that Web Part zones for a Web Part Page in
Windows SharePoint Services 3.0 should be created using the
WebPartZone control defined in the Microsoft.SharePoint.Web-
PartPages namespace and not the standard WebPartZone control from
ASP.NET 2.0. |
|
Instances of the WebPartZone control are
usually defined in content pages. The following code shows a simple
example of creating a content page designed to act as Web Part Page
in a Windows SharePoint Services 3.0 site. As you can see, this
.aspx file links to default.master just like the example you saw
earlier. However, it also explicitly inherits from the WebPartPage
base class and adds two WebPartZone controls into PlaceHolderMain.
![Figure 1-4 A Web Part Page in Windows SharePoint Services 3.0 requires the SPWebPartManager]( "Figure 1-4 A Web Part Page in Windows SharePoint Services 3.0 requires the SPWebPartManager")
Figure 1-4 A
Web Part Page in Windows SharePoint Services 3.0 requires the
SPWebPartManager control and one or more WebPartZone controls. If
you create a content page that inherits from the WebPartPage class,
you also get the benefit of Windows SharePoint Services 3.0
supplying Editor Parts and Catalog Parts.
When you create a Web Part Page for a
standard ASP.NET 2.0 application, you are required to add logic that
interacts with the WebPartManager control to manage the Web Part
display mode. Typically, you also need to explicitly add Editor
Parts and Catalog Parts to the page along with the HTML layout to
accommodate them. Fortunately, you don’t have to do these things
when creating content pages for a Windows SharePoint Services 3.0
site. Instead, you inherit from the WebPartPage class that’s defined
in the Microsoft.SharePoint.WebPartPages namespace and let it do all
this work for you behind the scenes.
Figure 1-5 shows a screen shot of a custom
Web Part Page in action. This is the display generated by the custom
Web Part Page definition shown in the previous code when the user
has entered edit mode. Notice that the page allows users to add Web
Parts into zones and to modify existing Web Parts using standard
Editor Parts.
![Figure 1-5 Custom Web Part Pages that inherit from the WebPartPage class provide automatic support for managing display mode as well as providing Editor Parts and Catalog Parts.]()
Figure 1-5
Custom Web Part Pages that inherit from the WebPartPage class
provide automatic support for managing display mode as well as
providing Editor Parts and Catalog Parts.
|
|
--> |