Defines common user interface (UI) properties used by ASP.NET WebPart controls.
Assembly: System.Web (in System.Web.dll)
Gets or sets the URL to an image that represents a WebPart control in a catalog of controls.
Gets or sets a brief phrase that summarizes what a control does, for use in ToolTips and catalogs of WebPart controls.
Gets or sets the title of a WebPart control.
Gets or sets the URL to an image used to represent a Web Parts control in the control's own title bar.
Gets or sets a URL to supplemental information about a WebPart control.
The 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.interface provides several UI-oriented properties that enhance the user experience of working with
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 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.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
Notes to Implementers:
Normally you do not need to implement the 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.interface, either on custom
The main reason to implement the 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.interface yourself, whether in a custom
The following code example demonstrates how to implement theinterface 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 WebPart class implementation, all the properties of the interface are implemented as personalizable as well, though they are not in this code example.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
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.
Available since 2.0