RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Work Web Part Magic Inside of ASP.NET

SharePoint users have known how useful Web parts are for a long time, but it wasn't until recently that every .NET developer had access to the ease and grace of Web parts using ASP.NET 2.0. Find out how you can use these handy content containers to create Web sites that put routine content sharing capabilities into the hands of your end users.

icrosoft released SharePoint to the market back in 2000/2001 and, in doing so, began a shift in perception about how Web applications are built. The change was slow at first and has yet to take over the way we build applications completely; however, the change has started.

Rather than the old way of building page after page of copied content, this change moves toward a development model for Websites that focuses on reusable, connectable, and user-configurable components that are assembled quickly in different ways to create the solutions that business users need. In the Sharepoint world, these reusable components are called Web parts.

Now, ASP.NET 2.0 has integrated Web parts and the core concepts behind it: the idea that you build applications from components and not as page after page of similar functionality. This core approach to software development has the potential to accelerate your business by allowing users to assemble their own software solutions—solutions that normally they would not be able to create on their own.

In this article you'll learn the core concepts behind an ASP.NET 2.0 Web part, how this structure relates to (and is better than) Windows SharePoint Services 2.0 (and Microsoft Office SharePoint Portal Server 2003), and how to build your own Web part page.

What is a Web Part?
At its most basic level a Web part is a Web control (or server control if you prefer) that supports an extra set of methods and properties. These methods and properties are designed to allow you to easily manipulate configuration data and appearance/UI elements programmatically.

In SharePoint a Web part had to derive from the Microsoft.SharePoint.WebParts.WebPart class. In ASP.NET 2.0 the key requirement is that the Web control that you want to use as a Web part implements the System.Web.UI.WebControls.WebParts.IWebPart. If you derive from System.Web.UI.WebControls.WebParts.WebPart the IWebPart interface is already supported for you. So you can build ASP.NET 2.0 Web parts just as you would have built a SharePoint Web part—by deriving from a base class.

ASP.NET 2.0 has a cool twist: It allows you to use any Web control as a Web part even if the Web control does not support the IWebPart interface natively. The ASP.NET 2.0 framework wraps the Web control in a generic wrapper and uses that wrapper to expose the necessary interface.

In terms of the functionality that a Web part can provide, there is little limit to the applications for the technology. Just as Web controls themselves are flexible, so too are Web parts. The ability for the business user to compose a page with a set of reusable components transfers the power that was once solely in the developers hands into the hands of the business user. Once a library of components is built up around internal business needs, the business users can begin to assemble their own pages.

ASP.NET 2.0 is fundamentally built on the premise that developers write code. So rather than a pre-made solution for adding Web parts to a page, ASP.NET 2.0 provides a set of building blocks that you can use to create a component-based model for building user interfaces—a model that leverages Web parts.
For instance, if the developer creates speedometer controls around the key performance indicators of the business, the business user can assemble a dashboard. If instead, the developer creates a set of search components that allow back-end ERP systems to be searched, an advanced search screen can be created which allows users to search across the entire enterprise from one page.

An HR application might include Web parts that talk about payroll information and might include links to the employee handbook, online training sites, and other components that are not individually complicated but can be powerful together.

Nearly every site or portal that you've ever seen demonstrated in Microsoft SharePoint can now be created with ASP.NET. While many cases expose SharePoint's built-in power of lists and document libraries, there are many others that demonstrate little more than the ability to create a central focal point of information through the use of Web parts.

Making a Web Part Work
In SharePoint using a Web part is the native way that things operate. There is no setup, no special configuration settings, and nothing to do except drop the Web part on the page in a Web part zone. However, with ASP.NET 2.0 there is no default understanding on every page to connect Web parts to the core infrastructure. ASP.NET 2.0 is fundamentally built on the premise that developers write code. So rather than a pre-made solution for adding Web parts to a page, ASP.NET 2.0 provides a set of building blocks that you can use to create a component-based model for building user interfaces—a model that leverages Web parts. There are two essential components to each page you create.

The most important component to a Web part page is the WebPartManager control. This control must appear once and only once on every page that will have Web parts. It must occur before any other element related to Web parts. It is responsible for coordinating control throughout the page. Even though it will display in design mode in Visual Studio it does not render any output to the page during runtime. It's simply there to be the "traffic cop" for the Web parts and the infrastructure.

The second essential item is the WebPartZone. The Web part zone is the container for the Web parts. Every Web part on the page should be placed in a Web part zone.

In addition to these two required components of the page you'll also need to ensure that personalization is set up on the site so that ASP.NET has a database in which to store the configuration of the Web parts.

Making Web Parts Valuable
Although technically, there are only two requirements to make Web parts work, they aren't the only useful components of the framework. "Zones" are containers for other controls. The ASP.NET framework defines three types of Zones. The first type is the required WebPartZone, discussed in the last section. There are two others that you will likely find useful:

  • EditorZone—This zone is responsible for holding the editor parts, which allow for the editing of appearance (AppearanceEditorPart), behavior (BehaviorEditorPart), layout (LayoutEditorPart), and custom Web part properties (PropertyEditorPart). This zone is essential if you want users to be able to personalize Web parts—either for all users of the current page or just for themselves.
  • CatalogZone—This zone is responsible for holding the catalog parts, which allow a user to add Web parts to a page. The three catalog parts are: PageCatalogPart, which allows the user to add Web parts to the page that were previously on the page but were closed; DeclarativeCatalogPart, which allows the developer to create a list of Web parts that can be added to the page; and ImportCatalogPart, which allows users to import Web part configuration from another site or location. The catalog zone is essential if you want the user to be able to add Web parts to the page.
In a typical portal type environment you'll place an editor zone, with the appropriate editor parts above a catalog zone, which has a set of catalog parts in it. When ASP.NET 2.0 renders the page these sections will be invisible until the page enters the appropriate mode. The way that SharePoint implements these zones is along the right side in a bar that appears when the page is in an editing or maintenance mode.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date