Let’s Talk DotNetNuke User Personalization

Welcome back! This is part III of the Making Your DotNetNuke Module Do More For You series. Last time I brought you some ways to have your module interact with the DotNetNuke page that it lives on: Utilizing Your DotNetNuke Module's Data Access Layer.

Amongst other things, I showed you how to read and write settings for your module instance. Today I will show you how to read and write unique values for each DotNetNuke user of your module.

The Personalization Namespace

To store and retrieve values that are unique to one particular user you can use classes from the DotNetNuke.Services.Personalization namespace. We will first be interested in the Personalization class within this namepace. The DotNetNuke.Services.Personalization.Personalization class contains a number of static (aka shared) methods that will get, set, and remove custom key-value pairs of data for an authenticated user.

Storing Personalization Data

SetProfile(ByVal NamingContainer As String, ByVal Key As String, ByVal Value As Object)

This version of SetProfile will store an object in the profile of the current authenticated user. If there is no authenticated user, this method does nothing. The first parameter NamingContainer is exactly what it sounds like, a naming container. In this context the NamingContainer string represents some entity with which you wish to associate the data. As a rule of thumb a module developer will use the current module instance for the naming container, unless it makes sense to make the naming container a different scope, like the PortalId or a constant name used between related modules.

The second parameter is a string type that is used to create a key for retrieving the data you are storing. You should use a meaningful name here. For instance, if you are storing the date of the user’s last visit, you could use the string “last_visit” as a key. You might also consider using your module or company name here to help you identify that data if it is ever seen by human eyes at the DAL layer.

The final parameter of the SetProfile() method is the data you wish to store. The parameter is of type object, so you could in theory specify anything here. However, this data gets serialized to xml behind the scenes, so you might keep in mind that the object you specify needs to play well with an XmlSerializer. It might help to implement the IXmlSerializable interface if you want control over how your custom class gets serialized and de-serialized.

In this example we store the string value “Purple” under the key “Favorite Color”, using the current module as the naming container:

The second method that the Personalization class has for storing data is an overloaded version of SetProfile() that takes an extra parameter in the front.

This method does the same thing that the original SetProfile() method does, except it allows you to specify a PersonalizationInfo object that contains the profile of the user that you want to store personalization data for.

This can be very useful if you need to initialize personalization info for all the users in a portal:

    1 // save some blog space, in all examples

    2 using DotNetNuke.Services.Personalization;

    3 using DotNetNuke.Entities.Users;

...

    1 // Instantiate a PersonalizationController

    2 // to use for loading profiles

    3 PersonalizationController persController

    4    = new PersonalizationController();

    5 

    6 // Get array of UserInfo,

    7 // containing all users in portal

    8 ArrayList array = UserController.GetUsers(PortalId);

    9 

   10 // Process each UserInfo

   11 // to set profile data

   12 foreach (object userInfo in array)

   13 {

   14    // get PersonalizationInfo object for user

   15    PersonalizationInfo persInfo

   16         = persController.LoadProfile(

   17             ((UserInfo)userInfo).UserID, PortalId);

   18    if (persInfo != null)

   19    {

   20         // initialize personalization information

   21         Personalization.SetProfile(

   22             persInfo,

   23             ModuleId.ToString(),

   24             "Favorite Color",

   25             "Purple");

   26    }

   27 }

The code above retrieves an array of UserInfo type, one UserInfo object for each user in the portal. A PersonalizationInfo object is retrieved using data from each UserInfo object. Then the PersonalizationInfo object is used to call the overloaded SetProfile method.

Retrieving Personalization Data

GetProfile(ByVal NamingContainer As String, ByVal Key As String)

The GetProfile() method retrieves the data you stored using the SetProfile() method. The first parameter is the naming container you used when you called SetProfile() to store the data. The second parameter is the key you used to store the data using the SetProfile() method.

The GetProfile() method returns the requested data as a simple object type, so you must re-box the object to its original type. GetProfile() will return an empty string if no user is authenticated.

The code above retrieves the string “Purple” (assuming you first initialized the “Favorite Color” entry using the first SetProfile() example above).

Just like the SetProfile() method, the GetProfile() method also has an overloaded version which allows you to specify a PersonalizationInfo object, so you can read a value from the profile of a particular user that isn’t necessarily authenticated.

GetProfile(ByVal objPersonalization As PersonalizationInfo, ByVal NamingContainer As String, ByVal Key As String)

The overloaded GetProfile() method might be useful if your module needs to perform different actions for different users, based on a particular piece of data in the profile of the user. For instance the following code could be used to contact all the users, each using the method they prefer:

The code above loops through the profiles of every user in the portal and contacts them based on the personalization data stored with the key "Contact Method".

Removing Personalization Data

RemoveProfile(ByVal NamingContainer As String, ByVal Key As String)

The RemoveProfile() method does the reverse of the SetProfile() method. That is, it will remove the personalization entry for the authenticated user. If there is no authenticated user, this method does nothing.

This method takes the same parameters as the GetProfile() method. The first parameter is the naming container you used to store data. The second parameter is the key you used to store the data.

Like both SetProfile() and GetProfile(), this method has an overload that allows you to specify a PersonalizationInfo object containing the user profile you wish to remove a value from.

RemoveProfile(ByVal objPersonalization As PersonalizationInfo, ByVal NamingContainer As String, ByVal Key As String)

This could be used to remove a personalization setting for all the users in a portal:

The code above loops through the profiles of every user in the portal and removes the personalization data stored in the current module's naming container with the key "Favorite Color".

To Summarize

1. You can store custom data for each user without creating custom DAL code by leveraging the DotNetNuke framework's Personalization namespace and Personalization class.
2. The Personalization class has methods SetProfile(), GetProfile(), and RemoveProfile(), which can (respectively) store, retrieve, and delete custom user data.
3. SetProfile(), GetProfile(), and RemoveProfile() each have an overload that allows you to specify a PersonalizationInfo object that contains the profile of a particular user that you wish to read or modify.

I hope you find the information in this article useful. Stay tuned for upcoming segments where I will show you how to dynamically create DotNetNuke pages (tabs) from within a module. I also hope to bring you a more detailed overview of the DotNetNuke user infrastructure.

Thanks for reading!