Personalization
Listing 9-22: Using SQL Server as the provider in the machine.config file
<configuration>
<system.web>
...
<profile enabled=”true” defaultProvider=”AspNetSqlProvider” inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”>
...
</profile>
...
</system.web>
</configuration>
This change forces each and every application that resides on this server to use the SQL Server provider instead of the Access provider, unless this command is overridden in the application’s web.config file.
Using multiple providers
You are not limited to using a single provider, such as the Access or SQL provider. Instead, you can use any number of providers. You can specify the personalization provider for each property defined. This means that you can use the default provider for most of the properties, whereas a few of them use an entirely different provider (see Listing 9-23).
Listing 9-23: Using different providers
<configuration>
<system.web>
<profile inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”
defaultProvider=”AspNetSqlProvider”>
<properties>
<add name=”FirstName” /> <add name=”LastName” /> <add name=”LastVisited” /> <add name=”Age” />
<add name=”Member” provider=”AspNetAccessProvider” />
</properties>
</profile>
</system.web>
</configuration>
289
Chapter 9
From this example, you can see that a default provider is specified — AspNetSqlProvider. Unless specified otherwise, this provider is used. The only property that changes this setting is the property Member. The Member property uses an entirely different personalization provider. In this case, it employs the Access provider (AspNetAccessProvider) through the use of the provider attribute of the <add> element. With this attribute, you can define a specific provider for each and every property that is defined.
Summar y
The new personalization capabilities provided by ASP.NET 2.0 make it incredibly easy to make your Web applications unique for all end users, whether they are authenticated or anonymous. This new system enables you to store everything from basic data types provided by the .NET Framework to custom types that you create. This system is more versatile and extensible than the use of Session or Application objects. The data is stored via a couple of built-in personalization providers that ship with ASP.NET. These providers include ones that connect with either Microsoft Access or Microsoft SQL Server.
290
Por tal Frameworks and Web Par ts
Internet and intranet applications have changed considerably since their introduction in the 1990s. Today’s applications don’t simply display the same canned information to every viewer; they do much more. Because of the wealth of information exposed to end users, Internet and intranet applications must integrate large amounts of customization and personalization into their offerings.
Web sites that provide a plethora of offerings give end users the option to choose which parts of the site they want to view and which parts they want to hide. Ideally, end users can personalize the pages, deciding for themselves the order in which the content appears on the page. They should be able to move items around on the page as if it were a design surface.
After pages are customized and established, the end user needs the capability to export his settings for storage. You certainly wouldn’t want to allow an end user to highly customize a page or a series of pages in your portal and then force him to reapply the settings each time he visits the site. Instead, developers need to take these setting points and move the items to a data store for later exposure.
Adding this kind of functionality is expensive — expensive in the sense that it can take a considerable amount of work on the part of the developer. Before ASP.NET 2.0, the developer had to build a personalization framework that would be used by each page requiring the functionality. This type of work is error prone and difficult to achieve, which is why in most cases it wasn’t developed.
But wait. . . .
Introducing Web Par ts
To make it easier to retain the page customization settings applied to your page by your application’s end users, Microsoft has included Web Parts in this release of ASP.NET. Web Parts, part of the larger Portal Framework, are an outstanding way to build a modular Web site that can be customized with dynamically reapplied settings on a per-user basis. Web Parts are objects in the
Chapter 10
Portal Framework which the end user can open, close, minimize, maximize or move from one part of the page to another.
The Portal Framework enables you to build pages that contain multiple Web Parts — which are part of the ASP.NET server control framework and are used like any of the other ASP.NET server controls. This means that you can also extend Web Parts if necessary.
The components of the Portal Framework provide the means to build a truly dynamic Web site, whether that site is a traditional Internet site, an intranet site, a browser-based application, or any other typical portal.
When you first look at Web Parts in ASP.NET 2.0, it may remind you of Microsoft’s SharePoint Portal Server. Be forewarned, however, that these two technologies are similar in name only. The ASP.NET team introduced Web Parts; the resulting Portal Framework is the basis of what is now also used by the SharePoint Portal Server, in addition to being offered in ASP.NET. Microsoft is simply creating singular technologies that can be used by other Microsoft offerings. In this process, Microsoft is trying to reach the Holy Grail of computing — code reuse!
The modular and customizable sites that you can build with the new Portal Framework enable you to put the Web page that is in view in several possible modes for the end user. The following list describes each of the available modes and what each means to the end user viewing the page:
Normal Mode: Puts the page in a normal state, which means that the end user cannot edit or move sections of the page. This is the mode used for standard page viewing.
Edit Mode: Enables end users to select particular sections on the page for editing. The selected section allows all types of editing capabilities from changing the part’s title, the part’s color, or even setting custom properties — such as specifying the end user’s zip code to pull up a customized weather report.
Design Mode: Enables end users to rearrange the order of the page’s modular components. The end user can bring items higher or lower within a zone, delete items from a zone, or move items from one page zone to another.
Catalog Mode: Displays a list of available sections (Web Parts) that can be placed in the page. Catalog Mode also allows the end user to select in which zone on the page the items should appear.
Figure 10-1 shows a screen shot of a portal utilizing the Portal Framework with the Edit Mode selected.
The Portal Framework is a comprehensive and thought-out framework that enables you to incorporate everything you would normally include in your ASP.NET applications. You can apply security using either Windows Authentication or Forms Authentication. This framework also enables you to leverage the other new aspects of ASP.NET 2.0, such as applying role management, personalization, and membership features to any portal that you build.
To understand how to build your own application on top of the new Portal Framework, start by creating a simple page that uses this new framework’s utilities.
292