Portals are changing the way people use the Internet. Users are getting accustomed to picking and choosing the pieces of content they want presented to them, virtually customizing the content and layout of a web or home page to the way they personally prefer to see it presented. With the implementation of Web Parts in the .Net 2.0 framework, you can add this functionality to your application with ease!
Contributed by Justin Cook Rating: / 21 November 28, 2005
The web is an incredibly useful tool for enabling people to get the information you want. However, the way we get that info is evolving. Up until recently, one would bookmark the sites with frequently changing content, and check back each day for updates. It would be kind of like reading through the daily paper; you’d visit your daily list of sites for updates on the weather, news, stocks, sports, comics, you name it!
It didn’t take a long time before someone realized “hey, it’s all just data, if I can devise some way to pull it all together in one place, let people pick and choose what and how much they want, it’ll be a hit.” And it turns out they were right! They slapped on the enticing moniker "portal," and now every person wants one, and every large website wants to provide one. I admit that even I have my own portal home page, and I use google.com/ig. This is no fad; this is the current direction of the Internet.
But where do Web Parts come into the picture? Well, no discussion of web parts would be complete without mentioning SharePoint. Microsoft’s SharePoint solution is more or less a knowledge/document sharing system. It is meant to be the central intranet application for businesses, and it made sense to build in "portal" functionality. After all, this would become the home page of each employee, and each department, so allow them to do the customization work themselves. That is where Web Parts were introduced.
The concept caught on, and was so popular that Microsoft decided to build it right into the .Net framework. This literally allows any .Net application to house Web parts, and become a portal of sorts. Let’s see how you can put them to use in your next application!
Web parts are basically beefed up panel controls. No, in fact, that’s exactly what they are, as the WebPart abstract class is actually derived from the Panel class! But instead of just the basic content holding block that is a panel, the Web Part has loads of additional interface elements as well as functionality, such as the ability to minimize and restore, as well as drag-and-drop.
Before I get into the code, I have to explain one more thing. You’re not actually going to implement a WebPart control on your page. As I mentioned, it’s an abstract class. So how do you get them on your page? Well, the simplest way is by creating user controls. These are contained in a collection of WebParts, by a control called a WebPartZone. The WebPartZone is also responsible for the layout of the WebPart(s) that it contains. You can have as many WebPartZones as you want on a page, containing many web parts. Of course, you can go through all the work of creating your own class by inheriting from the WebPart class, but it still needs to be wrapped in a WebPartZone. So, for the sake of simplicity, just use user controls!
You will also need to use a control called WebPartManager to manage all the WebParts on the page. Though it has no actual user interface, it is necessary to handle such things as remembering the visual state of the users’ WebParts.
So let’s assume that you’ve created two user controls, one that retrieves the weather, and one that retrieves stock quotes. I’m not going to detail the creation of these controls; you should be able to handle that yourself, or at least download some pre-built controls on the web to do this. I’m just going to show you how to register them on your page, and implement them as web parts. Here’s the code:
By looking as this code, it’s not readily apparent why I even bother throwing in all the extra code for the WebParts, when we could just toss the user controls right onto the page. However, by wrapping them in WebParts, we achieve some extra "stuff." By default, the WebPartZone will now throw a border and title on your WebParts (user controls) as defined in your site defaults. But very importantly, now you’re also given runtime rendering options. As in: each control displays two options: "minimize" and "close."
So that’s the ultimate basic implementation of web parts, but we have a number of properties available to us to modify the appearance and behavior of the web part. They are:
AllowClose
AllowEdit
AllowHide
AllowMinimize
AllowZoneChange
Caption
ChromeState
ChromeType
Description
Direction
HelpMode
HelpUrl
Hidden
IsShared
ProviderConnectionPoints
Title
TitleStyle
TitleUrl
Verbs
Zone
ZoneID
ZoneIndex
Most of these are self-evident as to their purpose. I’ll quickly explain those that perhaps aren’t as obvious:
AllowZoneChange: controls whether or not users can drag the Web part onto another zone.
ChromeState: sets the display state of the web part as normal or minimized.
ChromeType: modifies how the Web part is framed. The default is title and border, but you can set it to border, title, or none.
IsShared: determines whether multiple users are to share the Web Part.
ProviderConnectionPoints: used for communicating, or sharing data, between multiple Web parts on one page.
Verbs: allows you to modify the wording where "minimize/close/restore" appears.
Rather than setting these properties programmatically on an individual basis for each Web Part object, it is simpler to set properties in the zone, to apply to all Web Parts that are contained within. I’ll take the previous example, and add some formatting to it:
I changed a couple of the display settings here. To make the interface all the more user friendly, you could change the "verbs" (minimize/close) to images reminiscent of the same functionality in your favorite operating system. Here’s an example:
<CloseVerb imageurl=”~/images/x.png” text=”hide” Description=”close this section”/>
If you do this, the text property now becomes the alternate text for x.png, the image button used in its place.
If you are to deliver a truly personalized experience, you should allow users to arrange the web parts however they prefer. You do this by adding the personalization provider control to the page, called WebPartPageMenu, like this:
<asp:WebPartPageMenu text=”change this page” Font-Size=”9px” runat=”server” id=”myMenu” />
This gives users a menu with the following options:
Browse this page (default)
Add Web Parts to this page
Design Page Layout
Modify the Web Part Settings
Connect Web Parts on this page
Just as with everything else in the .Net framework, we’re not stuck with the default verbiage that Microsoft provides. In development we can redefine the verbs through the ModeVerb collection of properties.
By selecting a different option, the users enter the specified mode. They can move the web parts around by choosing design mode. If they move a web part to a new zone, the web part inherits that zone's defined visual properties. And the beautiful thing is that when you specify a data provider, any modifications they make persist. In other words, the next time that specific user visits the site, ASP.Net serves them up their page in the way they left it. Now that’s personalization!
Conclusion
Web parts are big, but they’re going to be huge. They allow us as programmers to do the initial coding to get them up and running, and hand off the rest of the work to the users, who needn’t know a line of code to customize their web pages. In the near future, they will no doubt be seamlessly integrated into everything that Microsoft produces for public consumption, such as the "My Space" available through MSN Messenger. The ability to build and consume Web Parts will become a required skill for any web programmers working in a company with a .Net based intranet website. So brush up now!
There are still three major components to Web Parts. Those are editing, the Web Part catalog, and interconnecting Web Parts. These will be the topic of a future article. For now you have enough information to keep you busy!
/ 21 
Manipulating Web Parts in ASP.Net 2.0
