Personalization is growing to be more and more of an essential ingredient in many types of Web apps, including portals and shopping sites. Without it, it's quite difficult to serve your customers efficiently. But building a personalization layer in your presentation tier can be a challenge. You need a persistent storage medium that is easy to manage and does not consume too many resources, you need an API to let page authors interact with the personalization store, and you need a data model that is easy to use and that provides type safety. Finally, you must provide both administrators and end users with tools to manage stored data and settings. Building a personalization layer in ASP.NET 1.x applications is definitely possible, but is tricky nonetheless. Thankfully, ASP.NET 2.0, provides new facilities to help you build your personalization layer with ease.
ASP.NET personalization features include user profiles, themes, error pages, and lots more. The ASP.NET user profile is designed for persistent storage of structured data through a type-safe API. To make use of personalization features, your application defines its own model of personalized data, and the ASP.NET runtime does the rest by parsing and compiling that model into a class. Each member of the personalized data class corresponds to a piece of information specific to the current user. Loading and saving personalized data is completely transparent to end users and doesn't even require the page author to know much, if anything, about the internal plumbing.
Themes in ASP.NET personalization assign a set of styles and visual attributes to the elements of the site that can be customized. These elements include control properties, page stylesheets, images, and templates. Custom error pages provide users with important information when an unhandled exception causes an error and stops the application. Next month I'll discuss themes and error pages, but for now let's look at user profiles.
Managing Personalization Data:-
While applying themes and attaching custom error pages is mostly a matter of editing the Web.config file with administrative privileges, managing the user profile of the currently logged-in user requires additional capabilities. In particular, a system-level infrastructure needs to retrieve and load the user's data when the request begins its processing. At the end of the request, the current settings should be persisted on the server to be retrieved with the next request issued by the same user.
Page settings can include any relevant, user-specific information such as a list of favorite links, the name of the selected theme, position of UI panels, and configurable strings. When necessary, an administrator can access the physical storage and edit user settings (this ability, however, depends on the provider in use; the default SqlProfileProvider stores data as opaque text or image blobs, so direct editing of the data is not easily done). To allow individual users to edit preferences, you need to provide a user interface. The most common way to do this is to add a few links in fixed areas of the page that when clicked cause the page to postback and an edit panel containing current values and controls to be displayed. A similar approach is implemented by My MSN® and SharePoint®-powered sites. The edit panels can be custom controls, or better yet, user controls. I'll return to this topic later in this column and provide a concrete example.
Managing User Profiles:-
A user profile is a collection of values that the ASP.NET 2.0 runtime groups as public fields of a dynamically generated class. The class is derived from a system-provided class and is extended with the addition of a few new members. The class doesn't have to be marked as Serializable, however its contents are persisted to the storage medium as individual properties. The storage occurs on a per-user basis and is preserved until an administrator deletes it.
The data storage is hidden from the user and, to some extent, from the programmers using the personalization APIs. The user doesn't need to know how and where the data is stored; the programmer simply needs to indicate what type of profile data provider she wants to use. The profile provider determines the store to use—typically, a database system like SQL Server™—and the layout of the data in the store. However, custom providers and custom storage models can also be used.
In ASP.NET 2.0 Beta 2, which I'm using for all examples in this column, the default profile provider utilizes SQL Server Express Edition, a free edition of SQL Server 2005. The physical storage medium is a local file named aspnetdb.mdf, usually located in the App_Data folder of the Web application.
When the application runs and a page is displayed, ASP.NET dynamically creates a profile object that contains properly typed data and assigns the current settings for the logged user to the properties defined in the data model. The profile object is added to the current HttpContext object and made available to pages through the Profile property. Assuming that the profile model has been defined to store a list of links as a collection, the following code snippet shows how to retrieve the list of favorite links that are created by a given user:
If Not IsPostBack Then
If Profile.Links.Count = 0 Then
Profile.Links.Add("http://www.apstechinc.com")
Profile.Links.Add("http://www.microsoft.com")
End If
End If
This code assumes a Links property in the profile object that references a collection type. When the page is loaded, Links and other properties are initialized to contain the most recently stored values; when the page is unloaded their current contents are stored to the persistent medium.
Your first step on the way to building a personalization layer is to define the layout of the profile object you want to use. You do this by adding a section to the app's Web.config file. In the end, the data model is a block of XML data that describes properties and related types. It consists of a list of properties, their names, and the corresponding managed type to be used to represent the property.
You add properties to the profile storage medium through name/value pairs. You define each pair by adding a new property tag to the <properties> section of the configuration file. The <properties> section is itself part of the larger <profile> section, which also includes provider information. The <profile> section, in turn, is located under <system.web>. The following code shows an example of a user profile section: