Configuring Personalization


To this point, we have relied on User scoped personalization exclusively. All personalization data has been scoped to a particular user. In this section, you'll learn how to enable Shared personalization scope so that you can enable administrators to make changes to an application for everyone.

You'll also learn how to configure the SqlPersonalization provider to store personalization data in a particular database in your computer network.

Configuring User and Shared Scope Personalization

To enable User and Shared scope personalization, you must authorize the group of users allowed to make personalization changes. By default, all users are allowed to make User personalization changes and no users are allowed to make Shared personalization changes.

The default personalization configuration settings are contained in the root Web.Config file located at the following path:

Windows\Microsoft.NET\Framework\v2.0.xxxxx\config\ 


The default authorization section is contained in Listing 29.3.

Listing 29.3. Web.Config

<webParts>   <personalization>   <authorization>     <deny users="*" verbs="enterSharedScope" />     <allow users="*" verbs="modifyState" />   </authorization>   </personalization> </webParts> 

The first authorization rule prevents any user from entering Shared authorization scope. The second authorization rule enables any user to personalize Web Part pages.

To authorize an administrator to make Shared personalization changes, you need to override these settings in the default Web configuration file. If you add the configuration file in Listing 29.4 to the root of your application, then anyone who is a member of the Administrators role can make Shared personalization changes.

Listing 29.4. Web.Config

<?xml version="1.0" encoding="utf-8"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">   <system.web>      <webParts>       <personalization>         <authorization>           <allow users="*" verbs="modifyState" />           <allow roles="Administrators" verbs="enterSharedScope" />         </authorization>       </personalization>     </webParts>   </system.web> </configuration> 

CD Note

The Web.Config file in Listing 29.4 is saved with the name Web.Config_listing4 on the CD so that it does not interfere with the other code samples in this chapter.


After you authorize a user or role to enter Shared personalization scope, you can place a page into Shared personalization mode in either of two ways. First, you can take advantage of the InitialScope property of the WebPartPersonalization class. If you want a page to open in Shared personalization mode by default, then you can declare the WebPartManager control in the page like this:

<asp:WebPartManager      Personalization-InitialScope="Shared"   Runat="server" />


This WebPartManager control declaration causes the page to enter Shared scope personalization mode by default. If a user requests the page and the user is authorized to enter Shared scope, then changes made to the page have Shared scope. If the user is not authorized to make Shared scope changes, then the page remains in User scope personalization mode (no exception is thrown).

Note

You cannot modify the IntialScope property after the Page PreInit event. What this means, in practice, is that you need to set this property declaratively. The ToggleScope() method gets around this limitation by automatically performing a Server.Transfer() back to the same page.


An alternate and in many situations better way to change personalization scope is to take advantage of the ToggleScope() method. Calling this method switches the page between User and Shared personalization scope.

The Personalization Manager created in Listing 29.1 includes a link that invokes the ToggleScope() method. If you want to experiment with Shared personalization scope, you can add the Personalization Manager to a Web Part Page and toggle between User and Shared scope.

Configuring the Personalization Database

By default, all personalization data is saved in a SQL Server 2005 Express database named ASPNETDB.mdf, located in your application's APP_Data folder. If you want to store personalization data in another SQL Server database on your network (for example, a SQL Server 2000 or SQL Server 2005 database) then you need to do two things:

  1. You need to set up the new database.

  2. You need to modify your application's web configuration file.

First, you need to add the necessary database objects for personalization to the new database. The ASP.NET Framework includes a command-line tool named aspnet_regsql, which automatically installs the necessary objects. This tool is located at the following path:

Windows\Microsoft.NET\Framework\v2.0.xxxxx\aspnet_regsql.exe 


If you run the tool without any parameters, the tool displays a wizard that walks you through the steps required for configuring a database for personalization (see Figure 29.2).

Figure 29.2. The ASP.NET SQL Server Setup Wizard.


Alternatively, you can execute a set of SQL Server batch files directly against a database. This is useful when you don't want to set up the .NET Framework on the server hosting your database. The same folder that contains the aspnet_regsql.exe tool contains the following four scripts:

  • InstallCommon.sql Installs the database objects that are used by several ASP.NET services such as the aspnet_Users table. Run this script first.

  • InstallPersonalization.sql Installs the database objects particular to Web Part personalization. Run this script after executing InstallCommon.sql.

  • UninstallCommon.sql Removes the objects added by InstallCommon.sql.

  • UninstallPersonalization.sql Removes the objects added by InstallPersonalization.sql.

After you add the necessary database objects for personalization, you can point any of your ASP.NET applications at the new database. For example, the Web configuration file in Listing 29.5 causes an application to store personalization data in a SQL Server database named AppData located on a server named DataServer.

Listing 29.5. Web.Config

<?xml version="1.0" encoding="utf-8"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">   <connectionStrings>     <add       name="DataServer"       connectionString="Server=DataServer;Trusted_Connection=true;       Database=AppData"/>   </connectionStrings>   <system.web>     <webParts>       <personalization defaultProvider="MyPersonalizationProvider">         <providers>           <add             name="MyPersonalizationProvider"             type="System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider"             connectionStringName="DataServer" />         </providers>         <authorization>           <allow users="*" verbs="modifyState" />           <allow roles="Administrators" verbs="enterSharedScope" />         </authorization>       </personalization>     </webParts>   </system.web> </configuration> 

CD Note

The Web.Config file in Listing 29.5 is saved with the name Web.Config_listing5 on the CD so that it does not interfere with the other code samples in this chapter.


The web configuration file in Listing 29.5 contains a <webParts> section that contains a <personalization> sub-section. The defaultProvider attribute points to a provider named MyPersonalizationProvider defined in the <providers> section. This provider uses the SqlPersonalization provider and uses a database connection string named DataServer.

The DataServer connection string is defined in the <connectionStrings> configuration section at the top of the configuration file. This connection string points to a server named DataServer and a database named AppData. You can, of course, provide a connection string for any database in your network.




ASP. NET 2.0 Unleashed
ASP.NET 2.0 Unleashed
ISBN: 0672328232
EAN: 2147483647
Year: 2006
Pages: 276

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net