Defines common user interface (UI) properties used by ASP.NET WebPart controls.
Assembly: System.Web (in System.Web.dll)
Thetype exposes the following members.
|CatalogIconImageUrl||Gets or sets the URL to an image that represents a WebPart control in a catalog of controls.|
|Description||Gets or sets a brief phrase that summarizes what a control does, for use in ToolTips and catalogs of WebPart controls.|
|Subtitle||Gets a string that is concatenated with the Title property value to form a complete title for a WebPart control.|
|Title||Gets or sets the title of a WebPart control.|
|TitleIconImageUrl||Gets or sets the URL to an image used to represent a Web Parts control in the control's own title bar.|
|TitleUrl||Gets or sets a URL to supplemental information about a WebPart control.|
The interface provides several UI-oriented properties that enhance the user experience of working with WebPart controls. When you create controls that derive from the base WebPart class, you get an implementation of all the properties in the interface, because the WebPart base class implements this interface.
You can use existing user controls, ASP.NET controls, or custom server controls that do not inherit from the WebPart class as part of a Web Parts application, and they can also use these UI-oriented properties declared by the interface. If you place existing server controls in a WebPartZoneBase zone, at run time they are wrapped with a GenericWebPart object. Because the GenericWebPart class inherits from the WebPart base class, it enables existing server controls to act as true WebPart controls and it adds to them the properties of the interface.
If you place server controls that are not WebPart controls in zones, they can use the properties at run time, and you can also declare values for those properties on server controls in the markup of the page (in page persistence format). However, because these properties are only available to the server controls at run time, design-time coding features such as IntelliSense do not recognize properties that are declared on server controls. Declared properties on these controls still work when you load the page, but Microsoft Visual Studio does not recognize the properties as valid at design time. If you want to add the properties to existing server and user controls to enhance the design-time user experience, you can implement the interface in a server control.
Perhaps the main reason to implement the interface is for controls that do not support the use of expando (custom) properties. Expando properties are strings that can be added to a class dynamically as a property, by means of the IAttributeAccessor interface. Controls that implement this interface, including the WebControl class and its children, can use expando properties. Therefore, all ASP.NET server controls, custom controls that derive from them, Web user controls, and WebPart controls support the use of expando properties. But custom controls that inherit directly from the base Control class do not support expando properties. Thus, if you declare these controls within a WebPartZone, you will not be able to declare the common properties on the controls, properties such as Title and Description. If you want to use these properties with such controls, you must implement the interface.Notes to Implementers
Normally you do not need to implement the interface, either on custom WebPart controls or server controls, because the base WebPart class already implements the interface. Custom WebPart controls, and other server controls that are placed in WebPartZoneBase zones, can use all the properties.
The main reason to implement the interface yourself, whether in a custom WebPart control or another server control, is if you want to change the default implementation. For example, you might want to provide default values for some of the properties. Another reason to implement the interface in a user or server control is so that the design-time experience of working with these properties on the control will be enhanced.
The following code example demonstrates how to implement the interface in a user control. This is a simple implementation that shows minimally how to implement the properties.
The first part of the code example shows the user control. The user control implements all the properties of the interface, plus two additional public properties tied to controls in the user interface. The two custom properties each use the Personalizable attribute, which enables the values in those properties to be saved across browser sessions. Note that in the base WebPart class implementation, all the properties of the interface are implemented as personalizable as well, though they are not in this code example.
The second part of the code example shows the Web page that hosts the user control. The page has a WebPartZone control, within which the user control is referenced. Notice that several of the interface's property values are set declaratively in the markup for the user control, which enables it to both behave and appear similar to a WebPart control at design time and run time. If you load the page in a browser, you can use the UI on the page to demonstrate the ability to programmatically change the values of the implemented properties at run time. When you change some of the property values, the changes are not evident on the page, but are visible in the page source (the TitleIconImageUrl property), or are stored in the application's state data (the CatalogIconImageUrl property).
This example has a text box that accepts user input, which is a potential security threat. By default, ASP.NET Web pages validate that user input does not include script or HTML elements. For more information, see Script Exploits Overview.
Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.