ASP.NET 2.0: WebPart Framework Basics

Looking at the Internet, I see a number of exceptionally functional sites personalized to my tastes. Much like staring at a map that says “You are here” and wondering, “Hmmm… how do they know where I am?!”, I am continually surprised at how advanced these sites are. A number of mature frameworks that free developers from mundane programming tasks have made this level of advancement possible.

Another thing that sticks out like a sore thumb is the level of reuse possible on most sites. For instance, every site has a header and banner. Some of them show a calendar, while others show forum-like applications. These reusable abstractions, or widgets, have been expressed in multiple ways in various application programming frameworks. In fact, entire products have been written on this concept of widgets; they just call them different names.

One such rather popular product was SharePoint Portal Server 2003, which called its reusable widgets WebParts. Thus, it makes perfect sense that ASP.NET 2.0 provides fantastic support for WebParts, and it definitely is no surprise to see Microsoft Office SharePoint Server 2007 (MOSS 2007) built upon this very framework. This article discusses WebPart framework basics, which can serve as the foundation for more advanced topics such as WebPart support in MOSS 2007.

The Major Components of the ASP.NET 2.0 WebPart Framework

Before diving into a sample WebPart-driven Web site, you must first understand the major reusable controls built into the .NET framework, which you will use to set up the site:

  1. WebPart: A WebPart is a reusable widget on a Web page. The user can choose to add a WebPart on his page, customize the WebPart per his needs, or even define communication between various WebParts. An ASP.NET 2.0 WebPart inherits from the System.Web.UI.WebControls.WebParts.WebPart class. A good example is a widget that displays traffic. End-user customization could involve specifying a freeway, and communication with another WebPart could involve a different WebPart that has a list of freeways that the user can click, one by one, to view updated traffic information. Setting up something like that is not very difficult in ASP.NET 2.0.
  2. WebPartManager: This control is the central policeman of the ASP.NET 2.0 WebPart framework. Each page should contain only a single WebPartManager, which is responsible for managing all functionality, events, and customization of various WebParts on that page. WebPartManager also has the ability to set various modes. So, for instance, if the user sets the WebPartManager in a Catalog mode, he could pick and choose the WebParts he wants on his page from a catalog of WebParts. Alternatively, he could put the page in Communication mode and define the various connections between different WebParts.
  3. Various Zones: Zones are physical areas on a page. These are implemented in the following Server Controls that ship with the Framework:
    • WebPartZone: A WebPartZone is a control that defines an area on a page where one or more WebParts can be hosted. A WebPartZone also controls the look and feel of a WebPart inside itself. Also, any control that doesn’t inherit from the WebPart class can masquerade itself as a WebPart and live inside a WebPartZone. This is done with the help of the GenericWebPart class, which inherits from the WebPart base class. By doing so, you are restricted to a subset of the functionality that a WebPart class can expose.
    • CatalogZone: The CatalogZone is the menu or the catalog from which a user can choose. It holds a number of CatalogPart controls, which in turn hold WebParts that are already added to the site and ready for the picking to add to various pages on the site. The user can pick WebParts from the Catalog, and add them to the various WebPartZones on the same page.
      There are three types of CatalogParts: DeclarativeCatalogPart, PageCatalogPart, and ImportCatalogPart.
    • EditorZone: This is the area on the page that prompts the user to edit his WebPart and customize it to his specific needs. A WebPart can also be customized in a Shared mode, where an administrator can configure the WebPart and all other users can view or use the WebPart but not customize it.
    • ConnectionsZone: This is the area of the page that prompts the end user to define communication between various WebParts on the same page. For instance, you could build an online RSS reader. One WebPart holds the user’s OPML, and the other WebPart renders the RSS for a particular subscription. The connection between the two would be the OPML WebPart providing a row (the RSS URL) and the RSS reader WebPart consuming the row, and then rendering appropriately. Because this is a simple ASP.NET 2.0 Web site, you can wrap these inside an atlas:UpdatePanel or a third-party control such as the telerik AJAX Panel. You even can eliminate postbacks and replace them with AJAX callbacks with almost no code at all.

Writing a Simple WebPart

Now that you familiar with the basic building blocks of the ASP.NET 2.0 WebPart framework, dive straight in and write your first WebPart.

You can masquerade any control using GenericWebPart, but that wouldn’t be a true WebPart because a true WebPart inherits from the Abstract base class System.Web.UI.WebParts.WebPart. So, the code for a simplistic WebPart that simply shows a line of text is as follows:

public class SimpleWebPart : WebPart
   private string displayText = "Hello World!";

   [WebBrowsable(true), Personalizable(true)]
   public string DisplayText
      get { return displayText; }
      set { displayText = value; }

   protected override void Render(System.Web.UI.HtmlTextWriter writer)

Don’t worry about the WebBrowsable and Personalizable attributes just yet—more on those shortly. For now, view this as a simple server control that renders the displayText, which is exposed as a public property: DisplayText. The obvious next question is: How can I make use of this WebPart?

Using a WebPart

Create a simple ASP.NET 2.0 Web site, and add a reference to the class library that holds the WebPart you just wrote. In the default.aspx, perform the following steps:

  1. Drag and drop an instance of the WebPartManager from the ToolBox.
  2. Drag and drop two WebPartZones (format them as you wish). To keep things simple, my WebPartZones look like this in design view:
  3. Now, add the SimpleWebPart you just wrote inside WebPartZone1. My page looks like this in Design Mode:
  4. Now, run this page. You should see your WebPart running successfully in the browser. You even have a neat menu next to the WebPartZone. When you do check Minimize (as shown below), the window even minimizes. Neat!

The code so far is really simple:

<form id="form1" runat="server">
   <asp:WebPartManager ID="WebPartManager1" runat="server">
   <asp:WebPartZone ID="WebPartZone1" runat="server">
         <cc1:simplewebpart id="SimpleWebPart1"
   <asp:WebPartZone ID="WebPartZone2" runat="server">

Also, note that the first time you ran the Web site, the SQL Express database ASPNETDB.MDF showed up as follows:

This is because the WebPart framework, much like a lot of other important functional blocks in ASP.NET 2.0, use that SQL Express database by default. If you were to customize your WebPart, move it between different WebPartZones, or perform any personalization that was tied to URL rewriting or the Membership API, and so forth, all of that information goes into that SQL Express database by default. Of course, all of that is very easily changeable thanks to the provider model and a few easy web.config changes.

You can do a number of really awesome things with the WebPart framework—way more than one article can cover. So far, you have seen very basic functions. What if the user wished to change the display text, or simply move the WebPart from WebPartZone1 to WebPartZone2?

More by Author

Must Read