Web Part Storage

When Web Parts are contained in a Web Part zone (dynamic Web Parts), properties are persisted by the base class in the SharePoint database.

Properties are stored based on the setting of the WebPartStorage attribute in the property definition (for more information, see WebPartStorageAttribute class). There are three possible values for this attribute:

• Storage.Shared, which means that the property is stored with the same value for all users.

  An example of this might be a Web Part that displays weather information and has a URL to a weather site as one if its properties. In this case, you'd probably define this property storage as Shared to make sure your part works as designed.

• Storage.Personal, which means that the property is stored per user (the default).

  If you are still designing the weather Web Part (as described above), you may want to define a property that contains a zip code, so that users of the part can choose the geographic area that they are interested in. In this case, by defining the property storage as Personal, users could choose the area they wished to view.

• Storage.None, which means that the property is not stored in the database, and the default value assigned by the designer is applied.

  Use this setting for properties containing values that don't need to be persisted (for example, a part containing your company logo).

Note  Each of the base class properties has a WebPartStorage attribute defined (this information is documented in each respective reference topic). A Web Part developer is responsible for setting this attribute for any custom properties that are added to a part, or defined in a custom Web Part.

When a Web Part is first added to a Web Part zone on a Web Part Page, the part is instantiated using a combination of all the Shared and Personal properties defined for the part. Once a user personalizes a part (for example, when the user moves the part to a different zone), a copy of the user's personal properties is stored in the database. The next time that part is instantiated, the Shared and new Personal properties are again combined, reflecting their changes. In the case of personalized parts, the database also tracks whether personalized parts are intended for display in Shared or Personal view.

The process of setting personal property values is known as personalization, and the process of setting properties for all users is known as customization. Developers determine the level of personalization and customization they require on a per-Web Part zone basis using the AllowCustomization and AllowPersonalization properties of the WebPartZone class. For example, a developer may choose to turn off personalization and/or customization on a high-traffic page or on a page that needs strict control. Given that personalization and/or customization also impact storage in the database, a site administrator may choose to apply restrictions for particular users.

Note  If Web Parts are placed directly on the Web Part Page, not in a zone, they are called static Web Parts and like standard Web controls, their properties are stored with the containing .aspx file.

For an example of how to define storage for a custom property in a Web Part, see Creating a Web Part with Custom Properties.