Last week I had a lunch meeting with the architects of a local company. The meeting began with a review of their current Web-based customer portal. This application had been deployed almost two years ago and had quickly become an important part of their business. Unfortunately, as they explained, the application had been a victim of its own success. With an increased customer demand and a broader set of business requirements it was slated for a substantial rewrite later this year. This was really what had brought us together that day. They had recently completed their initial user requirements, which only seemed to lead this group to additional questions. One of these questions regarded a new feature of ASP 2.0 called the Web Parts Framework. “It seems to be the answer to building portal applications and certainly looks to solve a lot of the requirements – but how can we use it?” they asked. In this article, I will explain as I did that day how the combination of Visual Studio 2005 and ASP.NET 2.0 with a new feature set called the Web Parts Framework can be used to build a reusable and customizable portal application.   

A portal is a specialized type of Web application that is designed to provide an additional set of value-added services not common in a typical Web application. Often these may include personalization, content aggregation, and data localization. Within a portal application, Web pages represent a set of markup that combine, reuse elements, and allow individual portal components to work together. Almost immediately, everyone in the meeting started to compare the Web Part Framework with what they had recently seen within their internal SharePoint Portal Server 2003 (SPS) implementation. Of course, I immediately agreed, the two are definitely very similar. However, the important difference is that the Web Parts Framework is designed entirely as an application framework leveraging the features of ASP 2.0. SPS however is an application that features a set of broad set of tools and components. One of these features includes the ability to build portal sites. Additionally, SharePoint Portal Server 2003 is not currently built on top of ASP 2.0 or the Web Parts Framework, but this should hopefully change in the future. Clearly, one of the design goals for future versions of SPS would be to leverage the existing features of ASP 2.0 and the Web Parts Framework.

In taking advantage of ASP 2.0 and Visual Studio 2005, the Web Parts Framework offers a variety of advantages. Probably the most important is the productivity enhancements that were added to this release. Across the entire platform this translates into a variety of additional features and enhancements. One of these within ASP 2.0 was the inclusion of out-of-the-box support for site membership and a new personalization service. The design goal of the personalization service was to enable the automatic storage and retrieval of user settings and preferences for Web-based applications. The Web Part Framework was built on top of this to provide a portal-based infrastructure that is designed to build, reuse, and customize Web pages. Each Web part page provides the ability to change the page layout, add and remove Web part properties, and establish connections between Web parts. Being built on top of the personalization features of ASP 2.0 also provided a built-in infrastructure that automatically persisted changes and ensures that they are
remembered for the next visit to the portal Web page.

The Web Part Architecture
Conceptually, the design of the Web Part Framework is based on a set of core components as shown in Figure 1. It’s this inherited combination of personalization, UI structural components, and Web Part UI controls that are merged together to form the Web Part Framework infrastructure. At the base is a base set of personalization provided by the ASP.NET 2.0 Framework. By taking advantage of the ASP.NET features, this enables the Web Part Framework to have the ability to automatically store user data and personalization information within a persistent store such as SQL Server 2005. It is this level that is responsible for managing and storing user-specific data – not just for the current browser session, like the view state, but for the long term. Within ASP 2.0 this persistence and personalization layer is generated automatically during the compilation of the application.

It is the combination of this stack that enables the set of Web Part server controls that appear in the Visual Studio 2005 toolbox as shown in Figure 2. These server controls provide both the core structure and additional services needed by developers to implement the Web Part Framework within their portal applications.
   
The single most important UI structural component is the Web Part Manager. This ASP server control is part of the namespace System.Web.UI.WebControls.WebParts. WebPartManager. Every Web page that implements the Web Parts Framework is required to have a single instance of this control. Although it is only visible during design time as shown in Figure 3, this control has the critical task of coordinating the orchestration of Web Parts, firing events when page state changes, and managing page personalization in conjunction with ASP.NET. Additionally, as pages become more complex this control enables the communication between Web parts.

Exploring Zones
Once an instance of the Web Part Manager is available on any ASP.NET page, the next set of structural components that must be added to the page is a zone as shown in Figure 4. Zones act as the layout manager for a Web Part Page. One or more zones are used to define both the default layout and appearance of Web Parts hosted within them. Zones are important in offering a consistent and common UI element across a Web Part page. These include header and footer styles, title, and border styles. The Web Part Framework provides several different types of zones each capable of hosting a unique type of Web part as described in Table 1.
 
Every Web Part page is composed of a main UI that contains at least one Web Part zone. By default, this zone is responsible for providing the overall page layout and is visible at all times, unlike the Catalog, Editor, and Connection zones, which are shown conditionally. However, all page zones maintain a connection with the WebPartManager through the public property WebPartManager.DisplayMode property. Setting this property determines the page’s current display mode and may conditionally show other registered zones. By default the WebpartManager.DisplayMode supports the values shown in Table 2.
   
The BrowserDisplayMode is one of the major keys to creating customizable Web pages. For example, if you have a Web Part page that contains both a CatalogZone and a WebPartZone, by default, when the page is loaded, only the WebPartZone is visible. In order to activate the CatalogZone and enable users to access the customization options that are available, you would use the following code.

WebPartManager1.DisplayMode = 
WebPartManager.ConnectDisplayMode

 
Zones are also responsible for providing Web Part chrome. The title bar and surrounding area of a Web Part is shown in Figure 5. Customizing the chrome is done through the WebPartZone public properties. These include the PartTitleStyle property, for example, that is used to define the appearance (color, font, etc.) of the title bar. The chrome also includes a PartChromeType property that enables the removal of both the title bar and border.
   
Web Part chrome also provides Web Parts with a standardized set of actions or verbs that are used to invoke customization. For example, the MinimizeVerb and RestoreVerb properties control the appearance of the buttons used to minimize and close Web Parts. The Web Part Framework also provides the ability to add a customized set of verbs in addition to the standardized set that is included. For example, in Figure 5, the Export, Edit, and Delete verbs were provided by the WebPartZone, while the Clear verb was added by the Web Part itself.

Building Web Parts
The final layer of the Web Part Framework is the UI control. Web Parts act as the main UI component elements of any Web Part page and serve as the main interaction point for portal users. In addition to creating your own custom controls, any existing ASP.NET server control, user control, or custom server control can be used as Web Part controls. It is important to remember that all controls within a Web Part zone are considered to be a Web Part. It is when a control doesn’t implement the IWebPart interface that ASP.NET places the part in a generic Web Part wrapper. This permits controls that weren’t written specifically to be Web Parts to be more tightly integrated within the Web Part environment. For example, once you create a zone you can drop any existing ASP.NET control such as a drop-down list box control onto the zone, which will render it as a Web Part as shown in Figure 6.
  
Of course, if you could only use the built-in controls this would limit the types of Web Parts and the value of the overall portal environment. However, this is where you can really start to develop more advanced types of Web Parts. For example, assuming the customer portal had a user control, this can also be dropped into a zone and rendered as a Web Part, as shown in Figure 7.
   
To take full advantage of Web parts, a control must be derived from the System.Web.UI.WebControls. WebParts.WebPart class. It’s this class that serves as base for the custom ASP.NET Web Parts. Deriving controls from this provides the ability to create connections, additional user interface properties, and personalization behavior. For example a custom Web Parts control could create a control to provide any of the features provided by other ASP.NET server controls, and that might be useful to package as a user-customizable Web Parts control: calendars, lists, financial information, news, calculators, rich text controls for updating content, editable grids that connect to databases, charts that dynamically update their displays, or weather and travel information. If you provide a visual designer with your control, then any page developer using Visual Studio can simply drag your control into a Web Parts zone and configure it at design time without having to write additional code.



Web Part Connections
Web Part connections enable the sharing of data across Web Parts and zones. Typically, you connect Web Parts together so that when an action is performed in one Web Part, it changes the content of another Web part, for example, if you can connect an Orders List View Web Part to the Image Web Part by passing data to it. Each time you select a row in the Orders List View Web Part it loads the image of the item ordered. This allows the portal users to see a picture displayed in the image Web Part of the item that they have ordered. Connections can be defined statically by page developers, or they can be created dynamically by end users within the ConnectionZone.

Programmatically, connections are maintained within a connection provider. The process of building a connection is simply writing a method that returns an interface and attributing this method with the [ConnectionProvider] tag. This tag requires two parameters. The first parameter assigns a friendly name to the provider connection and is displayed within the ConnectionZone UI. The second parameter assigns a unique ID to the provider connection point.     Providers are able to implement multiple connection points. However, each provider must be defined with a unique ID. For example, the following code creates a connection for the order interface.

<ConnectionProvider(“Get Orders”, “GetOrderProvider”)>  _

Public Function GetOrderInterface() As IGetOrder 

Return Me

 ‘ Assumes control implements IGetOrder

End Function

‘ IGetOrder.Getorder implementation

Public Function GetOrder() As String 

    Return _order

End Function

The underlying mechanics of Web Part connections is fairly simple as shown in figure 8. Within each page request, the WebPartManager enumerates all of the defined connections. If there are any found, it then calls the connection provider’s [ConnectionProvider] method to retrieve an interface and passes that to the corresponding connection consumer by calling the consumer’s [ConnectionConsumer] method. The connection consumer then makes calls through the supplied interface to return data back from the connection provider.

As the meeting began to wind down it was obvious how excited they were at the possibilities within the Web Parts Framework. As I began to leave they explained how they couldn’t wait to begin to get to work and start exploring further the possibilities within this new feature of ASP 2.0 and Visual Studio 2005. Like the meeting that day, this article only covered the basics of the Web Parts Framework; the rest is really up to you to discover.