ASP.NET 2.0 Web Part Infrastructure

Web applications today do a number of things. They could be a banking site, a content management system, or a news Web site. In spite of the diversity of Web applications available today, it almost always makes sense to break a Web page into smaller, reusable widgets that you can share in any other part of the site or even across sites.

This thinking has lead to reusable widgets such as the header and footer in your system, a huge third-party control vendor market, an emergence of portal Web sites such as my.yahoo.com or my.msn.com with functional widgets, and creation of products such as Plumtree and SharePoint Portal Server 2003.

SharePoint Portal Server 2003 and other such products heralded a new wave of technologies that enabled the creation and customization of Web sites by merely point and click at run time. These products came with a reusable and extensible set of widgets that users could drop on the surface of the page, and customize them per their specific needs. Given such a reusable set of widgets, and the ability to define their placement, behavior, look and feel, and even communication between them, it thus becomes extremely easy to set up and maintain sophisticated and highly functional Web sites.

It is thus not a surprise that ASP.NET has built-in support for such a widget-based or Web Part infrastructure. Also, it should not come as a surprise that in the future, this Web Part infrastructure will probably gain importance both inside and outside of Microsoft.

In this article, I’ll examine the basics of the ASP.NET 2.0 Web Part infrastructure. In a future article, I will dive into further details of the ASP.NET 2.0 Web Part framework. But instead of looking at only “theory” and a “rehash of MSDN,” I will instead build a real production Web site. This Web site will serve as my Web site at www.winsmarts.com, which is also where you can download this article’s code.

But before I dive straight into writing code for the Web site, let me begin by discussing the basic components of the ASP.NET 2.0 Web Part infrastructure:

• Web Part A Web Part is the reusable widget that the user can drop on to the surface of a Web page, customize it, and define communication with other Web Parts that may exist on the same page. A good way to think of a Web Part is that it is a server control on steroids that fits into the Web Part framework. As you will see further in this article, you can create your own custom Web Parts by inheriting from the System.Web.UI.WebControls.WebParts.Webpart class. You can also masquerade a user control or server control as a Web Part by encapsulating it in a GenericWebPart class. But by doing so, you get limited customization by implementing the System.Web.UI.WebControls.WebParts.IWebPart interface, and at least out of the box, you cannot leverage the inter-Web part communication infrastructure that ASP.NET 2.0 gives you.
• WebPartManager The WebPartManager is a server control that ships with ASP.NET 2.0. This is the central policeman of the Web Part infrastructure. It manages all functionality, events, and customization of various Web Parts on a given page. There should only be a single WebPartManager on a Web page. You can run the WebPartManager in one of several display modes. Based upon the current mode of the WebPartManager, the various other “zones” on the page appear or disappear. But what are zones? Zones are areas on a Web page that hold Web Parts, or other controls that let you customize the Web Parts on a page. This will become clear as I show you how to create a small Web site using the ASP.NET 2.0 Web Part infrastructure.
• WebPartZone A WebPartZone defines an area or zone on the page that can host one or more Web Parts. Any Web Part inside a WebPartZone inherits the look and feel controlled by the WebPartZone. Also, any control that is not a Web Part can also live inside a WebPartZone. This is done by masquerading the control as a Web Part with the help of the GenericWebPart class.
• CatalogZone The CatalogZone holds a number of CatalogPart controls. CatalogPart controls hold a menu or catalog of Web Parts that you can add to a page for the user to choose from. There are three kinds of CatalogPart controls.

1. DeclarativeCatalogPart The DeclarativeCatalogPart control allows developers to set up a catalog of controls in a declarative form.
2. PageCatalogPart If you were to choose a control from the DeclarativeCatalogPart and add it to the Web page, the control would now be “opened.” Now if you choose to close the Web Part from the menu at the top of the Web Part, the Web Part will now be closed. The PageCatalogPart maintains a list of closed Web Parts that were previously added to the page. In simpler terms, imagine a Web Part inside a DeclarativeCatalogPart as a class definition, and one in a PageCatalogPart as an instance of that class, with its properties set to user defined values. For example, if a DeclarativeCatalogPart holds a Web Part that has the ability to absorb and render an RSS feed, a good example of a PageCatalogPart would be to imagine two instances of the same RSS Feed control specified declaratively in the DeclarativeCatalogPart, pointed to two different RSS feeds.
3. ImportCatalogPart The ImportCatalogPart provides UI to the user to add new Web Parts into the system. This is done by “packaging” the Web Part into a standard XML format, and uploading it from a Web-based UI. This helps you create a system where you can add description files for newer Web Parts on a site that is already in production.

• EditorZone Most Web Parts need some degree of customization. For instance, a control that renders an RSS feed needs a public string property with the URL of the feed, and perhaps another integer property specifying the maximum number of news items to render. An HTML Content Web Part would need the HTML content specified, and maybe you would also want to specify the title for that Web Part, or maybe even its look and feel. The EditorZone hosts various EditorParts that allow the user to customize the various properties of any Web Part. ASP.NET 2.0 comes with a limited set of EditorParts or you can create your own by inheriting from the EditorPart class.
• ConnectionsZone When you have a number of Web Parts on a given page, it is reasonable to expect that some of these Web Parts may want to communicate with other Web Parts. For instance, a navigation Web Part may want to communicate with another Web Part to load the appropriate content. You can define this communication statically in a declarative form in the WebPartManager, or the end user can specify it dynamically by using a ConnectionsZone.

By: Sahil Malik

Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.

Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.

You should check out his blog at http://blah.winsmarts.com

sahilmalik@gmail.com