Web Parts Personalization Overview

Artículo
10/15/2014

In certain Web applications, you might want to allow users to modify, or personalize, the application's user interface and behavior. The ASP.NET Web Parts control set provides this capability in one of its core features, personalization. Personalization allows the properties or state of Web Parts controls to be saved in long term storage and not tied to a particular browser session.

How Personalization Works

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.

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 and Other ASP.NET Features

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.

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

Key Concepts in Personalization

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.

Control visibility	Page in Shared scope	Page in User scope
shared control (WebPart controls are shared by default)	An authorized user can personalize both Shared and User scoped properties on the control for all users. In the case of a dynamic control (a control that is added to the page programmatically, or from a catalog of controls), an authorized user can permanently delete it for all users. In the case of a static control (a control that is declared in the markup of an .aspx page), it cannot be deleted, although an authorized user can close the control for all users.	Individual users can not personalize properties scoped as Shared. They can personalize User-scoped properties, and their values for these properties take precedence over the property values assigned when the page was in Share scope. If the user-specific personalization data on a control is lost or reset, User-scoped properties revert to the values they had when the page was in Shared scope. Individual users can close a shared control for themselves, which adds it to the Page Catalog, but they cannot permanently delete it.
per-user control	The control cannot be personalized with the page in Shared scope, because the control does not even appear on the page. The control only appears when the page is in User scope.	Individual users can personalize both Shared and User scoped personalizable properties on the control for themselves, because the control instance is completely private. Individual users can also permanently delete the control.

shared control (WebPart controls are shared by default)

An authorized user can personalize both Shared and User scoped properties on the control for all users.

In the case of a dynamic control (a control that is added to the page programmatically, or from a catalog of controls), an authorized user can permanently delete it for all users.

In the case of a static control (a control that is declared in the markup of an .aspx page), it cannot be deleted, although an authorized user can close the control for all users.

Individual users can not personalize properties scoped as Shared. They can personalize User-scoped properties, and their values for these properties take precedence over the property values assigned when the page was in Share scope. If the user-specific personalization data on a control is lost or reset, User-scoped properties revert to the values they had when the page was in Shared scope.

Individual users can close a shared control for themselves, which adds it to the Page Catalog, but they cannot permanently delete it.

per-user control

The control cannot be personalized with the page in Shared scope, because the control does not even appear on the page. The control only appears when the page is in User scope.

Individual users can personalize both Shared and User scoped personalizable properties on the control for themselves, because the control instance is completely private.

Individual users can also permanently delete the control.

Essential Personalization Components

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.

Web Parts control	Description
WebPartManager	Manages all Web Parts on a page, enables or disables personalization, and manages the life cycle of personalization data. One (and only one) WebPartManager control is required for every Web Parts page.
WebPartPersonalization	Implements the logic necessary to carry out personalization actions.

Compartir a través de

Web Parts Personalization Overview

How Personalization Works

Personalization and Other ASP.NET Features

Key Concepts in Personalization

Essential Personalization Components

See Also

Reference

Concepts

Recursos adicionales