:: Home     :: MS Dynamics CRM     :: .Net 1.1     :: .Net 2.0     :: Sharepoint Portal     :: Ajax

  login:        
  passwords:  

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 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.

 

 
Google
 
-->
Copyright 2005-2015, Megasolutions Ltd  |   Privacy Policy