Page 1 of 2   next page »

For more than 20 years the software development industry has regarded reuse as the Holy Grail of software development.

Programming language-based object-oriented features promised to deliver the significant benefits of increased productivity and cost-effectiveness by creating reusable objects, but in industry-wide practice OO itself hasn't delivered the results we hoped for.

Enter "component-oriented development." As human beings we're "visual" beings. The ability to use visually represented objects come naturally to us and explains some of the popularity of programming processes like Visual Basic and ASP.NET with Visual Studio. The ability to create and distribute controls in whatever their file containments might be (.dll, .ascx, etc.) has been a boon to software developers.

With the use of components (non-visual objects) and control (visual objects) software artifacts we can leverage the reuse of functionality written either by ourselves or others, and ultimately create applications that would otherwise be impossible given the tight budgets and limited resources that business are confined by.

While the ability to create components has been available to application developers on the Windows platform since the mid-90s (and to "C" wizards well before that), user demands are evolving rapidly.

When I first connected to the World Wide Web in 1993, dynamic content were Web pages that were updated every few weeks. By late 1996 the end user's concept of "dynamic content" was beginning to change as developers began to use server-side processing technologies like Active Server Pages to generate an HTML page at the time a user made a request of their Web site.

As users of our Web-based application have become more and more Web savvy, their expectations of the user experience has evolved rapidly. In particular, the recent AJAX phenomenon has accelerated the dynamics and interactivity of many of the most popular applications on the Web, and users have come to expect this kind of experience as well as the ability to tailor that experience to their own desires.

Enter ASP.NET Web Parts.

Web Parts provide an extension to the ASP.NET control model that we've become accustomed to that adds the important aspects of customization and personalization, and those aspects can be determined by the developer or by the application user at runtime.

Users can, at runtime, be permitted to determine which Web parts will appear on their personalized Web page instance and how those part will appear.

To enable this ASP.NET feature developers must first create Web pages in the form of .ASPX pages that are prepared to contain Web Parts and interact with users so they can to make the desired choices at runtime.

An .ASPX page that will host ASP.NET 2.0 Web Parts must contain one and only one instance of the "WebPartManager" control and one or more "WebPartZone" control.

The "Web Part Manager" control is the enabler for using Web Parts on your page and the WebPartZones define section(s) of the page that can contain Web Parts. Zones are used to organize the page into related sections on the page.

Besides the WebPartZone there are two additional Zone controls that are at the ASP.NET developer's disposal: the CatalogZone and the EditorZone controls.

A CatalogZone serves as a container to enumerate the WebPart controls that are available for inclusion on the page, and the EditorZone contains the editors that the users will invoke to set the properties on the WebParts that are included on their Web page.

Figure 1 depicts the general architecture of an .ASPX page that's using Web Parts. Figure 2 shows this architecture in practice.

Note that this page has two visible zones, one that contains the left column and the other that contains the right-side column. The highlighted area is a single Web Part.

Clicking on the "Add stuff" link makes a catalog zone appear as shown in Figure 3.

Here users can select Web Part controls that offer the content or functionality of their choosing such as RSS collected new from various sources, topically specific searches, etc.

If the user clicks on the edit link in a particular Web Part, like the one highlighted in Figure 3, a part-specific editor appears.

The part-specific editor can contain any user customizations that the developer deems appropriate. The user can select how many items are to be displayed and whether or not to display images.

When the "Edit Mode" is enabled, Web Parts can move around in a Web Part Zone or even between zones. Web Parts can also be "connected" in the established property bindings between parts. For example, the property of one Web part can be used to constrain the data displayed in a different Web Part.

Any ASP.NET control can be used, without modification, as a Web Part. Any existing ASP.NET control, User Control, or Custom Control can simply be dropped onto an .ASPX page in a WebZone. This will cause an implicit call to the WebPartManager's CreateWebPart() method, which will create a GenericWebPart object instance and use the control that you added to your page to initialize that GenericWebPart object. One can use any standard control as a Web Part at design time or dynamically at runtime.

For the most part developing with Web Parts, once we understand the "Zone Architecture" is like developing with any other visual control in Visual Studio. Likewise, creating your own custom Web Parts has similarities to developing your own standard ASP.NET controls.

Creating Your Own ASP.NET Web Parts
The problem with using controls that aren't specifically designed to be Web Parts is that you lose most of the functionality expected of a Web Part. The developer must then start to add the properties expected of a Web Part back in by doing things like manipulating the GenericWebPart properties programmatically. While this approach is perfectly viable if it meets your needs, developers who are building Web applications that include this kind of functionality tend to prefer building fully "Web Part-enabled" controls.

Like standard ASP.NET controls, there are two general approaches to creating your own Web Part controls, User WebParts and Custom WebParts.

We can create a custom control that inherits from the "WebPart" base class. This method has the advantage of compiling to a binary .DLL and that .DLL is installable to the Global Assembly Cache (GAC).

Our class might look like Listing 1.

While building controls that compile, .DLLs make distribution easy and the control scope isn't limited to the application they're defined in, there are trade-offs.

There's no visual design experience.

We'll focus on building the UserControl-style

Web Parts. User WebParts can be created by creating an ASP.NET user control and implementing the IWebPart interface. Listing 2 shows a WebPart Class shell with the IWebPart Interface implemented.

Next, we need to add the visual elements of our custom user control. In our example, we'll add three text boxes that combine to form our custom control but you could use any ASP.NET control.

Remember, while this is a Web Part, it's also an ASP.NET user control so you can encapsulate whatever functionality that you want here.

Page 1 of 2   next page »