Web parts: the building blocks of portals

This article is an excerpt from Chapter 2, “Web parts: the building blocks of portals” from ASP.NET Web Parts in Action by Darren Neimke, published by Manning Publications. Reprinted here with the publisher’s permission.


You may already be acquainted with web parts and web part controls, and if you’ve worked with products such as SharePoint you have already used them quite extensively. (If these topics are not familiar, please dip into chapter 1 for a quick refresher.) Before you start this chapter, I recommend that you whet your appetite by seeing real examples of how web part controls allow users to customize the look and feel of web applications. To do so, visit http://Start.com. This is a web-based portal created by Microsoft Research. Notice how it provides a variety of methods to customize the page, by adding web parts and configuring them. For example, while at that page you could add a web part to display the current news from one of a dozen news providers, or display the weather for any city in the world. If you’re like me, you could lose many hours configuring that page to exactly suit your fancy. And guess what—once you’ve done it, it’s your page! Every time you visit that page, all the web parts you added, configured, and moved around will be there for you—just the way you left them.

In chapter 1 we learned that web parts are an integral aspect of a portal application. This chapter supplies a more exhaustive understanding of web parts, in particular how they are implemented in ASP.NET 2.0 portal applications.

This chapter is the first step in a journey through the properties, methods, and operations of web parts. In it we’ll learn how to add custom verbs to web parts and how to customize their look and feel through themes and other customization techniques. We’ll also delve a little deeper into the subject to see how web parts implement various interfaces that expose their behavior to the rest of the ASP.NET web portal framework. By the end of this chapter we’ll be well on our way to understanding how the http://Start.com website achieves its magic. Let’s begin!


Web parts are informational components, such as news updates or comics, that are added to web pages; and as such, web parts can be considered the primary building blocks of a portal application that displays dynamic content. In ASP.NET 2.0 we are provided with the WebPart server control for working with web parts. The WebPart server control comes pre-packaged with many properties and methods needed to use it in a variety of ways to show dynamic content to users.

The composition of web parts

A web part is generally rendered with a title bar, a border, and a body for displaying its dynamic content. The web part is manipulated by a web control that allows a user to work with and customize the web part. For example, users can set the web part’s height or width and provide it with a title and description. Other manipulations of web parts are accessed through small menu-like items known as verbs. These operations include performing tasks such as closing the web part, minimizing it, or connecting it to other web parts on the page. Figure 2.1 shows the basic elements that make up a standard web part control.

In figure 2.1 we can see the various subelements that combine to form a web part. Throughout this chapter we will learn more about each of these elements and see how to use the WebPart class to modify or affect each different element. Understanding how to gain access to each of these elements will take us a long way down the path towards having full control over how our web parts are displayed to the end-users of our portal.

Figure 2.1 The sub-elements of a Web-Part control.

Categorizing web parts

So far you’ve bumped into lots of buzzwords and phrases about web parts; but aside from a minor example, we have yet to learn exactly what they are. Are they simply common ASP.NET server controls? Or are they more like ASP.NET user controls? Do they ship as part of the core set of ASP.NET server controls? Answering these questions is logically the best place to begin our exploration of the ASP.NET WebPart control.

The simple example application that we built in chapter 1 showed that when we added standard ASP.NET server controls, the Calendar and the Label, to a web part zone, a transformation magically occurred—they became web parts. We saw that suddenly those controls had verbs, they now had titles, and they had properties that could be edited at runtime via the editor parts. To answer the question of “what is a web part?” we need to do some investigative work and discover more of the magic that turned those standard server controls into web parts!

2.2.1 Discovering the GenericWebPart control

In order to understand what happened to the Label and Calendar controls in the previous chapter, we’re going to need to put our debugging skills to the test and determine how all these web part controls interact with each other. To do that we’ll set up a web page and add web part controls to it. After that we’ll add code to the page that will access those parts. Finally, when we attach the debugger to the code and run it we’ll have a clear view of the state of those objects at runtime. Completing those steps will give us a much clearer view of how the transformation occurred.

NOTE This book is designed to be very hands-on, and as such we will frequently be writing small pages to try new things as we learn about them. Therefore, it would be a good idea to create a new ASP.NET project in Visual Studio that can be used to create ad-hoc web pages for testing. For the remainder of this book I’ll refer to this test project as “your test project.”

Creating a web page

Open your test project and create a new web page named GenericWebPart-Test.aspx. This page will be used to learn how these web controls are turned into web parts. As with all web pages that contain web parts, we must start by adding a WebPartManager control at the top of the page. Finally, we can add a WebPart-Zone and add a Label control to it. With that, our code should look like the following snippet:

<asp:WebPartManager ID="WebPartManager1" runat="server" />

<asp:WebPartZone ID="WebPartZone1" runat="server">
      <asp:Label id="ctl1" runat="server" Text="I'm a label" />

All that we know at this stage is that at some time between now and when this page is displayed in a browser, the Label control that we added to the web part zone starts looking and behaving like a web part. We know this because we saw that the label gained two characteristics common to web parts—a Title and Verbs—when it was contained within the web part zone in the previous chapter. Next we’ll write code that allows us to view the state of the page at runtime. Switch into the code section of the web page, enter the code, and set the debugging breakpoints that are displayed in figure 2.2.

Figure 2.2 Code and debugging breakpoints are used to inspect the state of controls on our page during the pre-rendering phase of the page lifecycle.

After an ASP.NET has been processing a good while, it enters into a phase that is referred to as the pre-rendering phase of the page. During the pre-rendering phase of the page, the OnPreRender event handler in the page is called by the ASP.NET engine, which causes code in our method to be executed. At this time, page execution will halt at the breakpoints that we’ve set. When the execution halts at runtime, we can inspect the state of the controls on the page at runtime. The control that we are interested in is WebPartZone1.

A WebPartZone control has two properties that are of particular interest to us because they will provide information regarding where our Label control is, and what type of control it is. These properties are called “Controls” and “WebParts” and, as you may guess from their names, they contain collections of controls that are contained by the web part zone. Logic would have us believe that the Label control will turn up in the WebPartZone‘s “Controls” collection because it is a web control but, from what we’ve observed, it’s pretty easy to expect that it will show up in the “WebParts” collection instead. Let’s run the page and see. From the Debug menu in Visual Studio, press Start Debugging to run the page and attach the debugger to it.

Debugging the page

The page runs and stops at the breakpoints, allowing us to place our mouse over the breakpoints and inspect the state of each variable. Hovering over the countOfWeb-Parts variable that we declared indeed does prove that the zone now contains one web part control as shown in figure 2.3.

Figure 2.3 While stepping through code in debug mode you can place the mouse cursor above variables to display their state.

Similarly, hovering over the countOfControls variable will display zero for its value. This tells us that the web part zone now believes that it contains no web controls. Hover over the last breakpoint and you’ll see that the name of the Type of the web part is GenericWebPart as displayed in figure 2.4.

Figure 2.4 Displaying the Type of the web part at runtime shows that it is no longer a Label but is now a GenericWebPart control.

With the page still in debug mode, right-click on the wp variable and choose the “Quick Watch” menu option from the resulting context menu. In response, the Quick Watch dialog is displayed for the wp variable allowing us to see the values for all of its properties. Figure 2.5 displays the Quick Watch dialog with many of the properties for the wp variable shown.

In the Quick Watch dialog we can see that the GenericWebPart has a large number of properties that do not belong to the Label class but, instead are members of the WebPart class. These properties include: “IsClosed,” “Title,” “CatalogIconImageUrl,” and “ChromeState” to name just a few. We see that there is also a property named “WebBrowsableObject” and that it is currently displaying a value of {Text = “I’m a label”}—the very same text value that we assigned to the original label in the mark-up for the page! This is quite a significant discovery, because it tells us that the very same Label control that we added to our WebPartZone earlier has been replaced with a new Type of control and has been wrapped by the WebBrowsableObject property. We can actually still get at the underlying Label control via the ChildControl property of the GenericWebPart—as demonstrated by the code in listing 2.1. Why would we want to get at the underlying control of the generic web part? One reason might be that we are using a control such as a GridView as the child control and we need to access the GridView after a page postback to re-bind it to a data source control.

Listing 2.1 The ChildControl property of the GenericWebPart provides access to the underlying web control that is wrapped by the GenericWebPart.

Having viewed the page at runtime, we saw that the portal framework elevated the label to the status of a web part by enclosing it within a GenericWebPart wrapper before adding it to the zone. This occurs for all non-web part controls that are added to web part zones, including user controls. Being able to create user controls and have them treated as web parts makes it possible to create web parts very rapidly and easily compared to the alternative—which is to create web parts directly by inheriting from the WebPart class. To get a feel for some of the differences, let’s take a look at what’s involved when we create web parts by inheriting from the WebPart class. In doing so we’ll better understand how to work directly with the WebPart class and we’ll also get to see how web parts are rendered.

More by Author

Must Read