Web Parts have become a hot topic for developers of late. Windows SharePoint Services v2.0 and SharePoint Portal Server offered developers the ability to create specialized pluggable custom components for SharePoint pages. These custom components operated in a WYSIWYG mode and the SharePoint infrastructure allowed designers to place page content dynamically by simply dragging these components around on a page at runtime. This was a radical new approach to the standard practice of creating user controls at development time.
With the introduction of ASP.NET 2.0 came inbuilt framework web parts. ASP.NET web parts added the same drag, drop; customize functionality for ASP.NET web sites that developers and designers experienced with SharePoint. The trouble was that neither implementation of web part technology was compatible. Legacy 2.0 web parts relied on the infrastructure in the SharePoint 2.0 shared library, whereas current ASP.NET web parts use the infrastructure in the .NET Framework.
Windows SharePoint Services 3.0 and Office SharePoint Server 2007 both support legacy WSS 2.0 web parts and new ASP.NET 2.0 web parts. All basic web parts in WSS 3.0 inherit from the ASP.NET 2.0 web part infrastructure, and plug in to SharePoint with no special development. An example ASP.NET 2.0 web part is below:
public class SampleWebPart : WebPart
// Persistent web part property
[Personalizable(), WebBrowsable(true), WebDisplayName(“My Property”)]
public int MyProperty
protected override void RenderContents(HtmlTextWriter writer)
SharePoint supports legacy web parts, which inherit from the base Control class, by rebasing the inheritance chain – The SharePoint infrastructure replaces the WebPart base class in the Microsoft.SharePoint.dll 2.0 with the WebPart class in the Microsoft.SharePoint.dll 3.0. All legacy web parts that inherit from the WebPart class automatically use the new WSS 3.0 infrastructure after rebasing, with no code change.
The ASP.NET 2.0 web part infrastructure requires a WebPartManager object instance on the page, as well as at least one WebPartZone object instance. The zone defines a segment in the page where web parts can exist, and the manager maintains the current location of parts in zones, the edit state of parts and persistence information. Page designers can drag web parts from one web part zone to another at runtime, as long as both zones exist on the same page. Specialized zones, such as the Editor Zone and Catalog Zone allow page designers to edit web part properties and select from a library of available web parts to display on the page.
SharePoint adds additional functionality to the ASP.NET web part infrastructure. If the SharePoint page inherits from the WebPartPage class – defined in the Micorosoft.SharePoint.WebPartPages namespace- then SharePoint includes an editor zone and catalog zone for you. By default, an instance of the SPWebPartManager class exists in the site master page. This class inherits from the standard WebPartManager class and provides functionality for persisting web part data to the SharePoint database, rather than the ASP.NET database.
Notice the Persistable and WebBrowsable attributes in the code above. These attributes permit the web part property to be persisted by the current web part infrastructure (be it ASP.NET or SharePoint), and show the property in edit zone controls.
This article is in no way exhaustive of web part functionality in SharePoint, but highlights the strategy to provide a common infrastructure to support legacy WSS 2.0 web parts and newly developed ASP.NET 2.0 web parts. Further reading will provide a deeper understanding of dynamic web part functionality and development. The following articles on the Internet contain valuable information for those readers looking to understand the technology in depth: