Practical ASP.NET

Web Parts Without Users

Want to give your users personalized pages without giving up control? It's easy with Web Parts. Peter shows you how.

• By Peter Vogel
• 08/20/2008

You have a Web page that you've added a lot of options to in order to support a wide variety of users. This one page supports adding new customers in Europe, customers in North America, customers in Asia; or, perhaps, you have one page that supports five different product lines.

Whatever the scenario, your page has become more complicated and harder to maintain. You've considered breaking this page up into several different (and simpler!) pages but there's a lot of code shared among the various options on the page. In addition to being hard on you, the plethora of options on the page is also hard on your users: Users are constantly wondering which of the many choices on the page they should be using.

What's especially irritating is that you know that any particular user either manages North American customers or European customers; that any particular sales person uses only one product line. Any one user really needs only one "option-less" page.

One of the benefits of object-oriented programming is that you end up with lots of small, easy-to-understand objects rather than one big, complicated monolith. Web Parts do the same thing for your user interface. Rather than create a single big, complicated page, Web Parts let you create multiple "partial pages" and allow the user to swap in the partial page they want. And if a user occasionally needs a different partial page (say, a salesman occasionally needs a part from a different product line), the user can swap in that partial page temporarily and, later, go back to their "regular" choice.

But when I tell my clients to start using Web Parts they tell me that they have no intention of letting users start making changes to the company's pages. I sympathize, but my clients are missing the point: Web Parts let you personalize the pages for your users but you can still stay in control.

Power to the Programmer
The strategy is to set up your page using Web Parts but give your users a limited range of options to implement (a RadioButtonList with the names of User Controls will do the trick). When the user makes a selection, you can implement their choice with less than 10 lines of code. This leaves you in complete control of what happens to the page but gives you all the benefits of personalization: Users pick the partial page they want and the page "remembers" their selection the next time they return.

Creating the individual Web Parts isn't hard; just create a user control for each option. Once your user controls are built, drag a WebPartManager onto the page you want to "Web Part-enable." After that, your page needs two things: a WebPartZone to display the user control your user selects and a CatalogZone with a DeclarativeCatalogPart inside it to hold your user controls (it's easy to add the user controls to the page -- just drag them into the DeclarativeCatalogZone in design view).

I'd put the code to swap in the user control in the SelectedIndexChanged event of the RadioButtonList and set the RadioButtonList's AutoPostBack property to True. With those settings, when the user selects an option from the RadioButtonList, you remove the user control currently in the WebPartZone, find the selected part (by name) in the CatalogZone, and move that control to the WebPartZone, ready for the user to start working with it. Here's the code that does that (I didn't even bother replacing the default names for the controls).

It's the best of all possible worlds: You give your users personalization but still stay in control.