The ASP.NET 2.0 Portal Framework

CoverStory

LANGUAGES: ALL

ASP.NET VERSIONS: 2.0

The ASP.NET 2.0 Portal Framework

Customize the Appearance, Layout, and Behavior of Your Content

By Zak Ruvalcaba

If you re an avid Internet junkie like me, you probably tend to frequent blogs, forums, resource sites, MSDN, etc. The Internet is becoming less information-centric and more community oriented, where participation, sharing, and involvement are key.

Let s face it, if you re reading this article, it s a safe bet that you probably spend close to a third of your day on the computer and ultimately on the Internet, possibly at one of the community oriented resources I just mentioned. Why? Because like our homes, the Internet is a place to sit back, relax, and read other opinions, do a bit of research, etc. Unlike our homes, however, we can t configure our online environments to suit our moods, customize and display what we want to see and interact with, etc.

We re basically stuck navigating the overwhelming lot of information that is presented to us in what is usually a one-dimensional, inaccessible, and non-aesthetically pleasing page of information slapped together by someone who is more concerned with the Wow, I got it to work mantra than anything else. It s safe to say that many of the sites on the Internet haven t caught up to the idea that people want personalization in their daily business practices and work preferences. So, as a developer, how can I create user-centric sites that allow my visitors/clients to change the layout, appearance, and even behaviors of the applications with which they interact? The answer to this question is solved by many new features introduced in ASP.NET 2.0, but none is more important than the Portal Framework.

An Introduction to Portals

Although the term portal has become increasingly foggy over the years, the premise has remained consistent. Portals are simply Web sites or services that offer a broad array of resources and services, such as e-mail, forums, search engines, online shopping malls, and, more recently, information customized based on the specific user. Figure 1 shows the My MSN portal for a registered user. In this example you can see that common information including Today on MSN, Weather forecast, My MSN, MSN City Guides, and more is readily available and centralized within a single page.

Figure 1: A My MSN portal for a registered user.

Today s portals are becoming increasingly more sophisticated, allowing the user complete customization of appearance, layout, and even the behaviors of the content within the portal. Figure 2 shows how a part of the My MSN portal can easily be moved from one location to another.

Figure 2: Part of the My MSN portal can easily be moved from one location to another.

All of this (and more) is available through the ASP.NET 2.0 Portal Framework. With the simple addition of a few tags to your page, you can create fully interactive, user-centric portals. Even better, because the Portal Framework is tightly integrated with ASP.NET 2.0 Personalization features, the layout, appearance, and even behaviors of the portal are customizable on a per-user basis, and are automatically retrieved the next time the user logs in.

Personalization

If you ve read about any of the newest features of ASP.NET 2.0, you ve no doubt stumbled across the topics of Membership and Personalization. The Membership infrastructure is designed to manage and store credentials for users; Personalization is a persistent user storage mechanism designed to store data related to the particular user of your application, such as:

common user information, like first and last name;
user application properties, like a shopping cart;
profile settings similar to ones used by forums; and
UI properties, such as the look and feel of a portal.

In general, if you want to programmatically work with properties of an individual user or allow your users independent customization of your site through the use of themes, skins, etc., working with Personalization is a necessity. For instance, in our portal we ll want to allow our user base to make individual customizations like layout, appearance, and behavior of the portal. Because this is the case, a new site needs to be created and minor configurations need to be made.

You can create a new site (to work with the examples in this article) and enable personalization for your site by following these steps:

1) Create a new folder within your Web server s default root directory (C:\Inetpub\wwwroot). I ll name mine Dorknozzle.

2) Open IIS and turn the folder into an application by right-clicking the project folder, selecting Properties, and choosing the Create button from the Directory tab.

3) Configure the application to use Integrated Windows Authentication by switching to the Security tab, then choosing the Edit button from the Anonymous access and authentication control panel. Next, uncheck Anonymous access and Digest authentication, making sure that Integrated Windows Authentication is selected. This will guarantee that the profile used in conjunction with our portal will be the default Windows user account.

4) Close IIS and navigate to the Web administration screen for your newly created application by typing http://localhost//WebAdmin.axd. Immediately, your application will be configured with the default AspNetAccessProvider. You can see that this is the case because the Data folder is created for you within the root of your application. Within that Data folder, you ll have the ASPNetDB.mdb database file, which is used to manage Personalization and Membership settings.

That s all there is to it. Now whenever a user accesses the portal site, we can be assured that a unique instance of the portal will be viewed by each user, which also guarantees that layout and appearance changes are persisted on a per-user basis.

The Portal Framework

The portal acts as the shell for which information is organized, but Web Parts are what really drive the look and customizability of the portal. Because Web Parts employ personalization features, Web Parts can be dragged from one location (otherwise know as zones) to another, minimized, and closed. Web Part styles can be applied on a per-user, per-Web Part basis, themes and skins can be applied, etc. Although functionality such as this would have encompassed significant effort in traditional ASP and even ASP.NET 1.x, it s really a snap in ASP.NET 2.0, requiring little more than declarative content (ASP.NET server controls).

The Web Parts Framework

As briefly mentioned in the last paragraph, Web Parts are little more than a library of server controls, organized within zones, to present a customizable portal similar to the previous screen grabs. Although Web Parts are the driving force behind the portal, they aren t self-relying. For instance, the WebPartManager (a non-visual server control), is required within all pages that use Web Parts. The WebPartManager is responsible for binding together all controls within the page, responding to events on the page, handling connections between Web Parts, etc. The WebPartManager can be added to the page by simply adding the control, as follows:

With that tag added and now out of the way, we can begin looking at the real components that drive how the portal functions. As previously mentioned, Web Parts are not self-contained and self-relying. Although in most cases we d be fine adding the WebPartManager along with a few simple controls, the real customization lies in the intricacies exposed by various other objects, including the WebPartPageMenu, WebPartZone, EditorZone, CatalogZone, and the various WebParts contained within those objects. Figure 3 better illustrates the object structure for a portal.

Figure 3: The object structure for a portal.

As you can see, the object structure of a portal page is fairly involved and, in most cases, uses a combination of the zones and Web Parts outlined. As you progress through this article, you ll get a solid understanding of how these objects function. In the meantime, the table in Figure 4 begins to detail these components.

Component	Description
WebPartManager	This component is responsible for binding together all controls within the page, responding to events on the page, handling connections between Web Parts, and calling methods on each Web Part.
WebPartPageMenu	This component allows users to switch modes so the layout of the portal can be changed, Web Part properties can be edited, and other Web Parts that may not be visible can be imported.
ConnectionsZone	Acts as a container for connections defined between Web Parts on a page.
WebPartZone	Provides a wrapper for Web Part controls. A typical portal page will contain many Web Part zones, each constituting a container within which other Web Parts can be moved into by the user.
EditorPart	The base class for editing controls on the page. Derived classes include AppearanceEditorPart, BehaviorEditorPart, LayoutEditorPart, and PropertyGridEditorPart.
EditorZone	Acts as a container for EditorPart components.
CatalogPart	The base class for catalog controls on the page. This part presents a list of available, unused Web Parts on the page. Derived classes include ImportCatalogPart, DeclarativeCatalogPart, and PageCatalogPart.
CatalogZone	Acts as a container for CatalogPart components.

Figure 4: Components of the object structure.

Aside from WebPartManager and WebPartPageMenu, a typical customizable portal page is made up of three parts: Web Parts, catalog parts, and editor parts. The Web Parts define the content that will be visible to the user, the editor parts allow the user to modify and customize the settings of Web Parts, and the catalog parts act as a library of available Web Parts that a user can add to their portal. If a user decides they don t want to see a particular Web Part, they need only to close the Web Part, in which case its reference is made available from the catalog.

Web Part Zones

Although it s possible to place Web Parts directly on the page, generally you ll want to make use of Web Part zones. Web Part zones, defined using the WebPartZone control, act as containers for your Web Parts and influence the layout, appearance, and behavior of the Web parts contained within them.

The WebPartZone control follows the same structure as other templated controls within the ASP.NET control library. For instance, the WebPartZone itself exposes generic properties for overall customization, child style tags for controlling the look of the output, and a zone template that contains the actual Web Part declarations. As an example of how to use the WebPartZone control, I ll add to my page the markup shown in Figure 5.

Figure 5: Using the WebPartZone control.

Viewing this example in the browser produces results similar to that shown in Figure 6.

Figure 6: Add the code from Figure 5 to get a page similar to this.

As you can see, the contents of the user controls (WebParts) are displayed within their respective zones. Even better, the page is somewhat customizable. If I click the Minimize button, the page posts back and a title bar is returned, complete with a Restore button similar to that shown in Figure 7.

Figure 7: This page is somewhat customizable.

If you d like to customize the text to include buttons instead of text, you need only change the CloseVerb-ImageURL, MinimizeVerb-ImageURL, and RestoreVerb-ImageURL properties for the WebPartZone.

Note: As you ll see throughout the article, user controls are one way of defining Web Parts. In this example, we ve used two user controls: Directory and Events. Not visible in the code example is the code contained within the user controls, which is available for download (see end of article for details). Also, the Register directive is not visible; the Register directive is still a requirement for including user controls within an ASP.NET page.

Examining the markup, you ll notice the form contains the required WebPartManager control and two WebPartZone controls. The WebPartZone control by default will show the title and a border. With some customization of various styles (PartStyle, PartTitleStyle, and VerbStyle) we can customize the look and feel of each zone. Next, within the WebPartZone controls, we use a tag. The tag includes all the Web Parts defined in the zone. Web Parts can be defined as:

User Controls. Referenced through a Register directive in the page, user controls act as the repository for your dynamic content and markup.
Compiled Assemblies. Referenced through a Register directive in the page, compiled assemblies will also act as a repository for your dynamic content and markup, but the underlying structure will change less frequently because of the compilation status.

If you studied Figure 3, you ll notice we re missing the GenericWebPart. It s important to note that WebPart is a generic abstract class that is used for referencing Web Part objects. To incorporate dynamic content within the page, you must use either a user control, a user control that inherits WebPart, or a compiled assembly. By default, the ASP.NET runtime wraps a user control into an instance of the GenericWebPart control, thus exposing basic Web Part capabilities such as minimizing, closing, captions, etc.

The WebPartPageMenu Control

In the previous example, you probably noticed we were restricted in the modifications we were able to make. Basically, with the controls that we added, we had limited functionality exposed to us, like minimize, close, and restore. What if we wanted to move Web Parts into other zones? What about customizing the look of the zone and Web Parts directly from the browser via a unique interface? The answer to these questions lies in the display modes that are supported by the WebPartManager. For instance, a typical portal page will support the following display modes:

DesignDisplayMode. When in this mode, the user is able to drag Web Parts from one zone to another.
CatalogDisplayMode. When in this mode, the user is able to select and add from a library of available Web Parts.
EditDisplayMode. When in this mode, the user is able to customize the layout, appearance, and behavior of the Web Part in edit mode.
BrowseDisplayMode. This is the default mode of the page. When in this mode, the user is limited to basic customization features, like minimize, restore, and close.

The control that is used to switch between these modes is the WebPartPageMenu control. When added to the form, the WebPartPageMenu control lists the display modes that the page currently supports. By default, the WebPartPageMenu control lists options for switching from DesignDisplayMode to BrowseDisplayMode. If I add an EditorZone and CatalogZone to the page, options for switching to CatalogDisplayMode and EditDisplayMode are listed within the control, as well.

It s extremely easy to work with the WebPartPageMenu control. In fact, like the WebPartManager control, the WebPartPageMenu control can be added anywhere on the page with one line:

As Figure 8 illustrates, options for switching between Browse and Design mode are listed in the dropdown menu.

Figure 8: Options for switching between Browse and Design mode.

You ll also notice that the mode which the page is currently in is highlighted as . Now if I switch to Design mode and click Change, the page posts back and the portal zone titles and borders become visible. Even better, as Figure 9 shows, I can drag one Web Part from one zone to the next.

Figure 9: Drag one Web Part from one zone to the next.

Of course, you can also customize the text that is displayed within the menu by changing the Text attribute of the various mode verbs:

Text="DESIGN PORTAL">

Editor Zones

As you ve seen, the first step to enabling dynamic editing on your portal is to simply add a WebPartPageMenu control. Unfortunately, the WebPartPageMenu control only goes so far. To provide complete layout, appearance, and behavior modification control to your users, you must define an editor zone. The editor zone, represented by the tag, defines various controls for customizing the appearance, layout, and behavior of the Web Parts within your portal. The controls supported by the editor zone are listed in Figure 10.

Editor Part	Description
AppearanceEditorPart	Allows you to edit visual settings like title, height, width, chrome type, visibility, and direction of text.
BehaviorEditorPart	As an administrator, allows you to edit the behavior (close, minimize, hide, zone changes, help features, etc.) of the Web Part for all users of the portal.
LayoutEditorPart	Allows you to edit layout settings such as the chrome state, zone placement, and index placement within a zone for a Web Part.
PropertyGridEditorPart	Allows you to edit the custom properties of the Web Part, assuming the control derives from the WebPart-derived class and it exposes a public property.

Figure 10: The controls supported by the editor zone.

You can add an editor zone, complete with editor parts, as shown in Figure 11.

Font-Names="Arial"

HeaderText="Edit Settings">

Runat="Server" />

Figure 11: Adding an editor zone complete with editor parts.

Like the WebPartZone control, the EditorZone control allows you to customize the look and feel of the control when in edit mode through various styles, including PartTitleStyle, HeaderStyle, InstructionTextStyle, and PartStyle. Also like the WebPartZone control, the EditorZone control s functionality resides within the tag. Initially, when viewed in the browser, you won t notice a significant change. However, take a second look at the WebPartPageMenu control. As Figure 12 indicates, you now have a third option listed, called Modify the Web Part Settings.

Figure 12: A third option, Modify the Web Part Settings, is now available.

If you select Modify the Web Part Settings, the page posts back and small dropdown menu icons will appear next to the minimize option within each Web Part zone s title bar. Choosing this option reveals the Edit functionality for the particular Web Part selected, as shown in Figure 13.

Figure 13: Select Modify the Web Part Settings to access the Edit functionality for the selected Web Part.

Selecting the Edit link reveals the Appearance and Layout customization options similar to that shown in Figure 14.

Figure 14: Selecting the Edit link shown in Figure 13 reveals the Appearance and Layout customization options.

As you can see from the image, the footer of the EditorZone control displays an OK button to confirm changes, an Apply button to save changes and continue, and a Cancel button to continue without saving. It s important to note that once you ve applied a change, that change is stored within the personalization data store; in our case, the aspnet_PagePersonalizationPerUser table within the ASPNetDB database located in the Data folder.

Note: You ve probably noticed that behavior settings are not visible, despite including the BehaviorEditorPart. The basic premise behind personalization and the portal framework is that we have administrators and users. By default, the portal opens in user mode, allowing only layout and appearance changes. Later in the article we ll discuss options for the administrator, also known as shared mode. It is here that we ll be able to make changes to the behavior of Web Parts.

Catalog Zones

By default, users are able to close every Web Part within the portal simply by clicking the Close button located in the upper-right corner of the Web Part zone. You can use the CatalogZone component, represented by the tag, as a way to provide users with the ability to re-add controls back to a zone once they ve closed them. Even better, the CatalogZone control supports the ability of allowing your users to browse for their own Web Parts via the ImportCatalogPart control, as well as to pick from a list of additional Web Parts that you expose at run time via the DeclarativeCatalogPart control.

Like WebPartZone and EditorZone, the CatalogZone control defines its functionality with the tag and offers three distinct controls as a way to define functionality (see Figure 15).

Catalog Part	Description
PageCatalogPart	Displays a list of available Web Parts to the user. Web Parts are only available within this list if they have been closed by the user first.
ImportCatalogPart	Allows users to manually search and import their own Web Parts for use within the portal.
DeclarativeCatalogPart	Allows you to specify additional Web Parts that should be made available to all users at run time.

Figure 15: The CatalogZone control defines its functionality with the tag and offers three distinct controls.

Like the controls that you ve seen to this point, CatalogZone also supports the formatting of various styles as a way to customize the look and feel of the zone. Figure 16 shows an example of a standard CatalogZone control added to the page.

Font-Names="Arial"

HeaderText="Web Part Catalog">

runat="server"

title="Cafeteria Menu" />

runat="server"

title="Company News" />

Figure 16: A standard CatalogZone control added to the page.

As you can see from the code sample, the CatalogZone control defines the three mentioned controls within its tag. Viewing this page within the browser also exposes a new option available to us (Add Web Parts to this Page) within the WebPartPageMenu control. Assuming I ve closed the Company Directory Web Part, if I select the Add Web Parts to this Page option from the menu, we are provided with the option of re-adding it to a zone via the Page Catalog option, as shown in Figure 17.

Figure 17: Select the Add Web Parts to this Page option from the menu to re-add it to a zone via the Page Catalog option.

You ll also notice that a dropdown menu of available zones is provided to help you choose in which zone to add the Web part. Selecting the Imported Web Part Catalog option exposes a unique interface similar to that shown in Figure 18 that allows users to manually browse for and add their own pre-built Web Parts to the portal.

Figure 18: Selecting the Imported Web Part Catalog option exposes a unique interface that allows users to manually browse for and add pre-built Web Parts to the portal.

Finally, we can select the Declarative Catalog link (shown in Figure 19) which exposes the two additional Web Parts (Cafeteria Menu and Company Events). Similar to the page catalog part, the user has the option of choosing the part they want to add by checking the available checkbox, choosing a zone to add the part to, and then clicking Add.

Figure 19: Select the Declarative Catalog link to expose two additional Web Parts, Cafeteria Menu and Company Events.

Shared View, User View, and BehaviorEditorPart

Similar to SharePoint, the Web Part framework supports the ability to distinguish between administrators and regular users of your portal via two supported modes: Shared Mode and User Mode. Shared Mode allows a user, typically accessible by an administrator, to configure the appearance and layout settings for all users of the portal. User Mode, which is the default state of the portal when Shared Mode settings are not enabled, allows customizations of the portal on a per-user basis. If you haven t noticed, we ve yet to discuss the BehaviorEditorPart control. BehaviorEditorPart, an administrative control, will never become visible, even when it resides within the tag of the editor zone. Because the behavior editor includes zone-specific options for all users, only the administrator will have access to this customization feature. To begin working with the BehaviorEditorPart, we must first enable Shared Mode. This can be done by creating a new web.config file within the root of your application and adding the code shown in Figure 20.

users="MyDomain\zak" />

Figure 20: Enable Shared Mode by creating a new web.config file within the root of your application and adding this code.

That s it! Notice we re simply adding the enterSharedScope and modifyState verbs for user MyDomain\zak. Assuming the user logs into the application, new options for Shared Mode and User Mode views will appear in the WebPartPageMenu control, similar to the example shown in Figure 21.

Figure 21: New options for Shared Mode and User Mode views in the WebPartPageMenu control.

You ll also notice that User Mode view is highlighted by default. Because my user s name is listed within the authorization section of the web.config file, I can now view the Behavior settings by performing the following steps:

1) Select the Show Shared View option from the page menu.

2) Click Change.

3) Choose the Modify Web Part Settings option from the page menu.

4) Click Change.

5) Click Edit from the desired Web Part s edit dropdown menu.

6) The Behavior settings will now appear similar to those shown in Figure 22.

Figure 22: The Behavior settings.

Among other functionality, the Behavior settings allow you to define whether or not users will be able to close, hide, minimize, change zones for Web parts, etc. Furthermore, you can provide users with a Help option for each Web Part in your portal. To demonstrate this, I ll select the Modal option from the Help Mode dropdown menu. Next, I ll enter help.htm within the Help Link textbox. Now I ll click OK and once again choose Edit from the Web Part s edit dropdown menu. Finally, notice that a Help link appears above the Edit link. Selecting the Help link reveals the Help box (if you created it) similar to that shown in Figure 23.

Figure 23: Select the Help link to reveal the Help box.

Conclusion

Creating fully interactive and user-centric portals in the past was a difficult task. As we ve seen in this article, ASP.NET 2.0 makes creating portals via a rich set of controls as easy as adding declarative content to the page with very little to no server-side code. Within the article we looked at the WebPartPageMenu control and how it facilitates switching between editing modes. We looked at creating Web Parts through user controls and how the various Web Parts can be added and moved within Web Part zones. We also reviewed the use of EditorZone and CatalogZone controls, including the parts associated with these zones to allow the user complete personalization in terms of layout, appearance, and behavior of the various Web Parts and zones within the portal. We also looked at how the WebPartManager control, a non-visual control, is added to the page to bind together all controls on the page. Finally, we looked at how you can make changes to the portal as an administrator through a simple addition within the web.config file.

Although this article briefly discusses some of the newest features in ASP.NET 2.0, it should get you excited enough to begin exploring the broad set of controls and, more specifically, get you building your own customizable portals.

The sample code in this article is available for download.

Zak Ruvalcaba has been researching, designing, and developing for the Web since 1995. He holds a Bachelor s Degree from San Diego State University and a Master of Science in Instructional Technology from National University in San Diego. Zak has developed Web applications for such companies as Gateway, HP, Toshiba, and IBM. More recently, he s worked as a wireless software engineer developing .NET solutions for Goldman Sachs, TV Guide, The Gartner Group, Microsoft, and Qualcomm. As an MCAD.NET and MCSD.NET certified professional, Zak also teaches at the San Diego Community College District on various technologies and tools, including ASP.NET, ADO.NET, and Web services. He is also the author of Build Your Own ASP.NET Website Using C# & VB.NET, available at http://www.sitepoint.com.

Comments

Plain text