Chapter 9
Adding a group of personalization properties
If you want to store a large number of personalization properties about a particular user, remember, you are not just storing personalization properties for a particular page, but for the entire application. This means that items you have stored about a particular end user somewhere in the beginning of the application can be retrieved later for use on any other page within the application. Because different sections of your Web applications store different personalization properties, you sometimes end up with a large collection of items to be stored and then made accessible.
To make it easier not only to store the items, but also to retrieve them, the personalization engine enables you to store your personalization properties in groups. This is illustrated in Listing 9-4.
Listing 9-4: Creating personalization groups in the web.config file
<configuration>
<system.web>
<profile inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”>
<properties>
<add name=”FirstName” /> <add name=”LastName” /> <add name=”LastVisited” /> <add name=”Age” />
<group name=”MemberDetails”> <add name=”Member” /> <add name=”DateJoined” />
<add name=”PaidDuesStatus” /> <add name=”Location” />
</group>
<group name=”FamilyDetails”> <add name=”MarriedStatus” /> <add name=”DateMarried” /> <add name=”NumberChildren” /> <add name=”Location” />
</group>
</properties>
</profile>
</system.web>
</configuration>
From the code in Listing 9-4, which is placed within the web.config file, you can see that two groups are listed. The first group is the MemberDetails group, which has four specific items defined; the second group — FamilyDetails — has three other related items defined. Personalization groups are
270
Personalization
defined using the <group> element within the <properties> definition. The name of the group is specified using the name attribute, just as you specify the <add> element. You can have as many groups defined as you deem necessary or as have been recommended as good practice to employ.
Using grouped personalization properties
From Listing 9-4, you can also see that some items are not defined in any particular group. It is possible to mix properties defined from within a group with those that are not. The items not defined in a group in Listing 9-4 can still be accessed in the manner illustrated previously:
Label1.Text = Profile.FirstName
Now, using personalization groups, you can access your defined items in a logical manner using nested namespaces:
Label1.Text = Profile.MemberDetails.DateJoined
Label2.Text = Profile.FamilyDetails.MarriedStatus
From this example, you can see that two separate items from each of the defined personalization groups that were defined were accessed in a logical manner. From the defined properties, you can see that each of the groups has a property with the same name — Location. This is possible because you are using personalization groups. With this structure, it is now possible to get at each of the Location properties by specifying the appropriate group:
Label1.Text = Profile.MemberDetails.Location
Label2.Text = Profile.FamilyDetails.Location
Defining types for personalization properties
By default, when you store personalization properties, you store them as type String. It is quite easy, however, to change the type to something else through configurations within the web.config file. To define the name of the personalization property along with its type, you use the Type attribute, as shown in Listing 9-5.
Listing 9-5: Defining types for personalization properties
<properties>
<add name=”FirstName” type=”System.String” /> <add name=”LastName” type=”System.String” /> <add name=”LastVisited” type=”System.DateTime” /> <add name=”Age” type=”System.Integer” />
<add name=”Member” type=”System.Boolean” />
</properties>
271
Chapter 9
The first two properties, FirstName and LastName, are cast as type String. This isn’t actually required. Even if you omitted this step, they would still be cast as type String because that is the default type. The next personalization property is the LastVisited property, which is defined as type System.DataTime and used to store the date and time of the end user’s last visit to the page. Beyond that, you can see the rest of the personalization properties are defined using a specific .NET data type.
This is the preferred approach because it gives you type-checking capabilities as you code your application and use the personalization properties you have defined.
Using custom types
As you can see from the examples that show you how to define types for the personalization properties, it is quite simple to define types that are available in the .NET Framework. Items such as System.Integer,
System.String, System.DateTime, System.Byte, and System.Boolean are easily defined within the web.config file. But how do you go about defining complex types?
Personalization properties that utilize custom types are just as easy to define as personalization properties that use simple types. Custom types give you the capability to store complex items such as shopping cart information or other status information from one use of the application to the next. Listing 9-6 first shows a class, ShoppingCart, which you use later in one of the personalization property definitions.
Listing 9-6: Creating a class to use as a personalization type
VB
<Serializable()> _ Public Class ShoppingCart
Private PID As String
Private CompanyProductName As String Private Number As Integer
Private Price As Decimal Private DateAdded As DateTime
Public Property ProductID() As String
Get
Return PID
End Get
Set(ByVal value As String)
PID = value
End Set
End Property
Public Property ProductName() As String
Get
Return CompanyProductName
End Get
Set(ByVal value As String)
CompanyProductName = value
End Set
End Property
Public Property NumberSelected() As Integer
Get
272
Personalization
Return Number
End Get
Set(ByVal value As Integer)
Number = value
End Set
End Property
Public Property ItemPrice() As Decimal
Get
Return Price
End Get
Set(ByVal value As Decimal)
Price = value
End Set
End Property
Public Property DateItemAdded() As DateTime Get
Return DateAdded End Get
Set(ByVal value As DateTime) DateAdded = value
End Set End Property
End Class
C#
using System;
[Serializable]
public class ShoppingCart
{
private string PID;
private string CompanyProductName; private int Number;
private decimal Price; private DateTime DateAdded;
public ShoppingCart() {}
public string ProductID
{
get { return PID; } set { PID = value; }
}
public string ProductName
{
get { return CompanyProductName; } set { CompanyProductName = value; }
}
public int NumberSelected
{
get { return Number; }
(continued)
273
Chapter 9
Listing 9-6: (continued)
set { Number = value; }
}
public decimal ItemPrice
{
get { return Price; } set { Price = value; }
}
public DateTime DateItemAdded
{
get { return DateAdded; } set { DateAdded = value; }
}
}
This simple shopping cart construction can now store the end user’s shopping cart basket as she moves around on an e-commerce site. The basket can even be persisted when the end user returns to the site at another time.
Take a look at how you would specify from within the web.config file that a personalization property is this complex type. This is illustrated in Listing 9-7.
Listing 9-7: Using complex types for personalization properties
<properties>
<add name=”FirstName” type=”System.String” /> <add name=”LastName” type=”System.String” /> <add name=”LastVisited” type=”System.DateTime” /> <add name=”Age” type=”System.Integer” />
<add name=”Member” type=”System.Boolean” />
<add name=”Cart” type=”ShoppingCart” serializeAs=”Binary” />
</properties>
Just as the basic data types are stored in the personalization data stores, this construction allows you to easily store custom types and to have them serialized into the end data store in the format you choose. In this case, the ShoppingCart object is serialized into a binary object in the data store. The SerializeAs attribute can take the values defined in the following list:
Binary: Serializes and stores the object as binary data within the chosen data store.
ProviderSpecific: Stores the object based upon the direction of the provider. This simply means that instead of the personalization engine determining the serialization of the object, it is simply left up to the data store.
String: The default setting. Stores the personalization properties as a string inside the chosen data store.
XML: Takes the object and serializes it into an XML format before storing it in the chosen data store.
274