The previous installment of this series, Working with Scripts and Master Pages, demonstrated the continuing need to use scripting as part of your Web application solution. However, addressing the mechanics of your application is only a first step. Most users today want to customize their Web experience by removing items they don't use or by making the items they do use more prominent.

As companies make more information available online, the need to customize the user experience becomes more important. You could write code to address this need, but creating and testing such code is time consuming. Fortunately, you can bypass many of the coding requirements by adding WebParts to your application.

Working with WebParts alone isn't very difficult. The most difficult part is defining precisely how you plan to create customization opportunities for the user. You can see the basics for WebPart usage in my article, Designing with WebParts in Visual Web Developer. However, working with WebParts and master pages together can present a few problems. For example, you need to consider where to place the various WebPart controls and ensure the master and content page work together properly.

Deciding on WebPart Management

The first issue to consider is where to place the WebPartManager control. Generally, if you plan to provide customization, you want to provide it for the entire Web site. Placing the WebPartManager on the master page makes sense, in this case, because you could also provide common content elements.

Of course, there's always the argument that not every Web page will require customization. For example, you wouldn't want the user to customize a help request form or a project survey. In this case, you'd need a second master page — one without the WebPart technology — or you'd need to disable the WebPart technology based on the content of the content page.

Not every Web site requires customization throughout. For example, if you're running a search or information service, you might want to provide customization on just the user's personal page. Adding the WebPartManager to the content page works fine in this case because only one or two pages will have the customization feature. This second method of working with the WebPartManager control is similar to working with standalone Web pages (those that don't rely on a master page), so the example explores working with WebParts in an environment where the developer splits the customization over the master page and content page.