|
The next version of SharePoint introduces new ways of building web parts through ASP.NET 2.0 Framework, as well as offering standard SharePoint web part support. Lots of developers may get confused about the differences between the two web part frameworks and when to use what. This article covers the technical details about both frameworks and how they fit into the next version of SharePoint sites.
Overview
SharePoint web parts provide support to create both customized and personalized user interfaces. Customization in this case means that the changes for the web part are seen by all site users. Individual users can personalize their web pages further by adding, moving and removing web parts in their view of the web page. In this case, personalization means that the changes made to the web parts are only visible to the user who made the change.
When developing custom web parts, you can extend the Windows SharePoint site's functionality in an easy and powerful way.
Web parts were first introduced in Windows SharePoint Services (WSS) V2.0. In Windows SharePoint Services 3.0 they are no longer just a SharePoint feature, because the ASP.NET team adopted the web part concept and rebuilt the entire web part framework using ASP.NET 2.0.
Because Windows SharePoint Services V3.0 uses .NET Framework 2.0, WSS web parts can also use the ASP.NET 2.0 web parts control set. When you are creating web parts for WSS V3.0, you have the option of inheriting from the System.Web.UI.WebControls.WebParts.WebPart (ASP.NET 2.0 web part) or Windows SharePoint Services web part class. The Windows SharePoint Services web part class was part of Windows SharePoint Services V2.0, before the ASP.NET web parts were introduced, where they supported web part development.
Developers can now easily apply their .NET development experience and use Visual Studio 2005 to create new ASP.NET 2.0 web parts for Windows SharePoint Services V3.0 sites.
Windows SharePoint Services (WSS) V3.0 Web Part Infrastructure
The WSS V3.0 web part infrastructure uses many of the ASP.NET 2.0 web part control sets. The infrastructure also creates its own controls by inheriting them from the base class provided by the ASP.NET 2.0 web part control set.
There are three controls that make up the core web part infrastructure in WSS V3.0. They are SPWebPartManager, WebPartZone and WebPart.
SPWebPartManager Class
WSS V3.0 web pages don't use standard ASP.NET WebPartManager in their pages. Windows SharePoint Services 3.0 uses the SPWebPartManager (Microsoft.SharePoint.WebPartPages.SPWebPartManager) that inherits from the ASP.NET WebPartMnager (System.Web.UI.WebControls.WebParts.WebPartManager) class. (There is an additional "SP" character in the SharePoint WebPartManager). The reason for having different names in ASP.NET and SharePoint is that the WebPartManager is a new concept introduced by ASP.NET web part controls. SPWebPartManager acts as the central hub, managing all the web parts and zones. In WSS 2.0 site pages, many of the tasks handled by SPWebPartManager were done by web part pages (adding, removing, moving web parts to zones, etc), web part zones, and the web part itself.
By default, the SPWebPartManager object is added to the master page of the WSS V3.0 pages. The SPWebPartManager is included in every content page by default because the master page contains an instance of SPWebPartManager. Because it's already set up for you, you can add a web part to a WSS V3.0 page without having to worry about the SPWebPartManager object.
All web parts now belong to the SPWebPartManager object in a page. This means a reference to the Parent property of the web part class will return SPWebPartManager object rather than the WebPartZone object in WSS V2.
WebPartZone Class
The WebPartZone provides a way to organize the web parts in to regions in the web page. WSS V3.0 uses its own WebPartZone (Microsoft.SharePoint.WebPartPages.WebPartZone) that is inherited from the standard ASP.NET 2.0 WebPartZone (System.Web.UI.WebControls.WebPartsWebPartZone) class. The same name is used in both ASP.NET web part control and WSS 3.0 web part controls. This is because the WebPartZone concept was introduced in WSS V2.0 and having the same name supports backward compatibility.
The WebPartZones control the appearance of the web part controls. Each zone is rendered as an HTML table in the browser. A page can contain more than one WebPartZone control. There are two types of WebPartZones:
- WebPartZoneBase - Contains all the web parts in the web part page.
- ToolZone - A specialized zone that enables users to change the properties of the web parts within the selected zone.
The SPWebPartManager and WebPartZone controls manage the serialization of the web part's data with the Windows SharePoint Services content database. ASP.NET web parts must be placed on a page with these two controls, if you want the data to persist and to support personalization.
WebPart Class
ASP.NET 2.0 web parts will run on both ASP.NET web pages and WSS site pages. You can build a web part for WSS V3.0 site that drives from:
- System.Web.UI.WebControls.WebParts.WebPart
- Microsoft.SharePoint.WebPartPages.WebPart
When you create web parts for WSS 3.0 sites, Microsoft recommends using ASP.NET 2.0 web parts rather than SharePoint web parts. An exception to this is when you require additional functionalities that are not part of ASP.NET 2.0 web part control set, but which are provided from SharePoint web parts. I will be looking at those special scenarios later in this article.
Differences between ASP.NET 2.0/WSS V3 and WSS V2
| |
ASP.NET 2.0/WSS V3 |
WSS V2 |
| SPWebPartManager |
New concept. Handles adding, moving, removing, personalizing, importing, exporting and managing connections between web parts. |
Did not exist. The web part, web part zones and the pages look after the work of SPWebPartManager. |
| WebPartZone |
Includes header, footer, border and CSS style sheet support to provide a common user interface for all web parts. |
Was not easy to control the user interface of all the web parts within a web part zone. |
| Web Parts |
Supports ASP.NET 2.0 and WSS V3 |
WSS V2 only |
| Web Part Parent property |
The web parts belong to SPWebPartManager object in the page. The Parent property of a web part will return SPWebPartManager object. |
Web Part belongs to web part zone object. The Parent property of a web part will return the WebPartZone object. |
| Web Part Connections |
Connections are referenced, based, and managed by SPWebPartManager or WebPartManager.
ASP.NET 2.0 supports unlimited provider connections, but is limited to a single consumer connection. |
Based on event handlers and web parts that handle the connections between them.
Supports unlimited provider and consumer connections. |
Importing and Exporting Web Parts
You won't be able to simply copy your ASP.NET 2.0 web parts to Windows SharePoint Services V3.0 pages. To use your ASP.NET web parts in the SharePoint environment, you must first export your ASP.NET web parts and then import them to the SharePoint pages. (The Building ASP.NET 2.0 Web Part for Windows SharePoint Services 3.0 and Microsoft SharePoint Server 2007 article covers more details)
When to Use Windows SharePoint Services Web Part Class
There are a few cases when you will have to use Windows SharePoint Services web parts instead of ASP.NET web parts. Windows SharePoint Services web parts support additional Windows SharePoint Services features that are not supported through an ASP.NET web part. Following is a list of features that are only supported through Windows SharePoint Services web parts:
- Connections between web parts that are outside of a Web Part zone
- Cross page connections
- A data caching infrastructure that allows caching to the content database
- Client-side connections (Web Part Page Services Component)
Another reason for using Windows SharePoint Services web parts is when you want to upgrade your Windows SharePoint Services V2.0 web parts to the V3.0 environment. The new version of the web part should be driven from the SharePoint web part class. SharePoint web parts can only be hosted in Windows SharePoint Services site pages.
Conclusion
Developers now have two sets of web part frameworks to work with. It is important to understand the difference between the two frameworks and when to use the appropriate framework to deliver wanted functionality. I will be looking at more code driven examples in the "Building ASP.NET 2.0 Web Part for Windows SharePoint Services 3.0 and Microsoft SharePoint Server 2007"article.
About the Author
Gayan Peiris (MVP, MCSD, MCAD, MIT, BComp) is an expert in architecting and designing SharePoint
Portals and Windows SharePoint Services solutions. He has written many articles, reviews and columns for various
online publications. Gayan is a frequent speaker at Microsoft developer conferences on SharePoint technology.
He has been a leading SharePoint advocate since 2001 and is president of
the Canberra SharePoint User Group.
Gayan been presented with
MVP award for Microsoft Office SharePoint Portal Server.
Gayan works as a Technical Architect/Principal Consultant for Unique World Pty Ltd
in Canberra, Australia. He can be reached at
http://www.gayanpeiris.com and
http://gpeiris.blogspot.com.
|
