Friday, May 2, 2008

Webpart personalization infrastructure

Read the following post which is mostly taken from MSDN, if you are having problem due to ASP.NET personalization provider. This might be required when you are trying to dynamically add/delete webparts and the inconsistent behaviour is observed; specifically when user logs in.

WebPartPersonalization implements low level personalization infrastructure.

This class implements the logic required to carry out lower-level personalization operations. Although the WebPartManager class manages the high-level life cycle of personalization, it is the WebPartPersonalization class that is responsible for actually implementing the physical steps necessary to carry out specific personalization actions. The WebPartPersonalization class in turn relies on an implementation of PersonalizationProvider to communicate with the underlying data store for personalization information.

The WebPartPersonalization class works closely with a WebPartManager control and the rest of the personalization infrastructure.

If you want to create a personalization subsystem significantly different from that provided by the WebPartPersonalization and the WebPartManager classes, you should create a custom WebPartPersonalization implementation by deriving from WebPartPersonalization and add your own custom logic. Then create a custom WebPartManager implementation by deriving from WebPartManager, add your own custom logic, and override the CreatePersonalization method to return your custom WebPartPersonalization implementation. Because a WebPartManager control makes requests to the personalization infrastructure by way of a WebPartPersonalization instance, the WebPartManager control does not directly interact with or hold references to PersonalizationProvider implementations.

No comments: