Personalization enables you to create properties for Web Parts controls that have several unique characteristics. Personalizable properties are:

• Tied to the identity of a specific user and Web page. Each user's settings for the personalizable controls on each page can be saved in personalization data. This data enables users to modify the UI on a Web page and save their individual preferences.

• Long-lived. Personalized settings are not tied to a single browser session. Because they are stored in long-term storage, the application can retrieve a user's settings each time the user visits a specific page.

  Personalization uses an ASP.NET application services database to store personalization data. By default, ASP.NET creates this database automatically in a subfolder named "app_data" when an ASP.NET application first uses personalization or one of the other application services such as roles, membership or profiles. Also by default, ASP.NET creates the database as a single SQL Server Express database file that contains the database schema for all of the application services. Using the Web.config file, you can configure your application so that a separate database file is created for personalization. Further, in the Web.config file, you can specify a SQL Server database to store the application services data instead of using the default SQL Server Express database file.

• Persisted through a provider layer. The mechanism for storing and retrieving personalization data consists of a provider component and a data store. ASP.NET includes a default Microsoft SQL provider and database. You can also create a custom provider and configure it to use any data store.

• Declarative on any Web Parts control. When you are developing a custom control, you can add the Personalizable attribute in code to enable a particular property on any Web Parts control for personalization. In addition to custom controls derived from the WebPart class, this also applies to ASP.NET server controls, custom server controls, or user controls, since they can be used as Web Parts controls.

  Note:

  It is important to recognize that ordinary properties are handled differently in that they cannot be persisted like personalizable properties. If you add a WebPart control or other server control to a WebPartZoneBase zone programmatically, and you try to set its non-personalizable properties programmatically (for example, if you set the Text property on a Label control), the properties are reset to their default values after the controls are added, because there is no way for these property values to be persisted in long term personalization storage. To persist the properties in long-term storage, they must be marked with the Personalizable attribute in the source code. Alternatively, if you want to persist the properties only across requests within the same browser session (but not in long-term storage), you can use view state.

Personalization contrasts in several ways with the other ASP.NET techniques for persisting a Web application's state data:

• Personalization is a feature of Web Parts. You cannot use personalization by itself. To use personalization, you must use controls within a WebPartZone so they will have Web Parts functionality.

  Note:
  Any ASP.NET server control, custom control, or user control can be used as a Web Parts control to take advantage of personalization.

• Personalization is different from view state. View state and personalization both persist control state data, but view state data only persists during the current browser session, while personalization data is long-lived.

• Personalization is different from profiles. Personalization stores user-specific state data for controls on a particular Web page only. Information that relates to the user as a person, and that is intended to be used across multiple pages in a Web application (such as account information in a shopping cart application), should be kept in a profile. For more information, see ASP.NET Profile Properties Overview.

When you use personalization with Web Parts controls, you should understand several concepts that affect how personalization works.

The first concept is page personalization scope. Page personalization scope is the range of users to which personalization changes on a page can apply. At any given time, a Web Parts page can be in one of two possible page personalization scopes, Shared or User. In Shared scope, any personalization changes on the page apply to all users; in User scope, personalization changes on the page apply only to the current user.

A second and related concept is control visibility. Control visibility determines whether a given control is visible to an individual user or to all users. Each WebPart control on a page is either a shared control, visible to all users of that page, or a per-user control, visible only to an individual user. Visibility is determined by how a control is added to a page. If a control is added by declaring it in the markup of a Web page (a static control), it is always a shared control. If a control is added by application code or by a user selecting it from a catalog of controls (a dynamic control), visibility is determined by the current personalization scope of the page. If the page is in Shared scope, a dynamically added control is shared, and if the page is in User scope, the control is a per-user control.

A third important concept is property scope. When you create a personalizable property on a control using the Personalizable attribute in the source code, you can set the personalization scope for the property to either Shared or User (User is the default scope). This provides detailed control over which properties on a control can be personalized by all users, and which can be personalized only by authorized users when the page scope is Shared.

Taken together, these concepts of page personalization scope, control visibility, and property personalization scope create the range of options for how Web Parts controls can be viewed and personalized by users. The following table summarizes how Web Parts controls behave when users personalize them in the various scopes.

The following table shows the two components in the Web Parts control set that are essential to personalization, and that you work with directly or indirectly whenever you use personalization.

Concepts

Reference