Creating a Data-bound Web Parts Control
By inheriting from the WebPart base class, you can give Web Parts capabilities to an ordinary data-bound server control. In Web Parts applications, end users are able to modify (personalize) the behavior and user interface (UI) of server controls, and have their settings saved in long-term storage for future browser sessions. Users can drastically change the look and feel of a page by adding or removing controls, editing the properties and appearance of controls, rearranging the page layout, importing or exporting settings for the controls, and even forming connections that enable controls to share data. To learn more about Web Parts applications, see the topics listed in ASP.NET Web Parts Controls. This topic describes the prerequisites for using a custom, data-bound WebPart control (or any server control) in a Web Parts application, and summarizes some members of the base WebPart class that are often useful to implement or override when creating a custom control. An example of overriding and implementing some of these members is provided in the topic Data-bound Web Parts Control Example.
Required Elements for using a Web Parts Control
No Web Parts control can run in isolation and still retain its Web Parts features. If you run a WebPart control in a Web application without the other required elements for a Web Parts application, the control simply loses its Web Parts features and functions as an ordinary server control. The following list explains the required elements that must be in place before you can use a custom WebPart control with Web Parts features:
The WebPartManager control. This control must be present on every page that offers Web Parts functionality. For details, see Web Parts Control Set Overview.
A WebPartZoneBase zone control. A Web page must have a zone that derives from this abstract class, such as the WebPartZone control, to contain WebPart controls. For details, see Web Parts Control Set Overview.
An ASP.NET Web site that can recognize individual users, using Windows or Forms authentication. For details on creating a virtual directory or site, see How to: Create and Configure Virtual Directories in IIS 5.0 and 6.0 or How to: Create and Configure Local ASP.NET Web Sites in IIS 6.0.
A configured personalization provider and database, to store user settings on controls. Web Parts personalization is enabled by default, and it uses the SQL personalization provider (SqlPersonalizationProvider) with the Microsoft SQL Server Express (SSE) edition to store personalization data. This walkthrough uses SSE and the default SQL provider. If you have SSE installed, no configuration is needed. SSE is available with Microsoft Visual Studio 2005 as an optional part of the installation, or as a free download from Microsoft.com. To use one of the full versions of Microsoft SQL Server, you must install and configure an ASP.NET application services database, and configure the SQL personalization provider to connect to that database. For details, see Creating and Configuring the Application Services Database for SQL Server. You can also create and configure a custom provider to use with other, non-SQL databases or storage solutions. For details and a code example, see Implementing a Membership Provider.
Commonly Overridden or Used WebPart Members
Although any type of server control can be used in Web Parts applications, there are some benefits to creating custom WebPart controls (for details, see Using ASP.NET Server Controls in Web Parts Applications). When you inherit from the WebPart base class, there are no required members to implement. There are, however, some commonly used members that you might want to use or override, and these are summarized in the following table. For a complete example of a data-bound server control implemented as a WebPart control, see Data-bound Web Parts Control Example. The following table summarizes some of the commonly used members.
Member |
Description |
|---|---|
WebPart |
A common usage for this constructor is to set default values on some of the properties that determine the appearance and behavior of a WebPart control, like the properties inherited from the Part class, or behavioral properties such as the AllowEdit and AllowLayoutChange properties. |
Behavioral properties |
This includes a number of the "Allow" properties of the class, such as AllowClose, AllowConnect, AllowEdit, AllowMinimize, AllowLayoutChange, and AllowZoneChange. Rather than simply assign default values to these properties in the constructor, developers can completely control a property, for example by preventing users or developers who use the control from ever being able to close the control. |
When you inherit from the WebPart class, you need to provide a UI for your custom control. A very effective way of doing this is to override the CreateChildControls method and, in this method, add other server controls to make up the UI of your custom control. You might need to carry out additional tasks when you add these controls, such as creating custom event handlers for them, or binding them to a data source. |
|
Rendering methods |
You might need to override common rendering methods such as RenderControl or RenderContents. In these methods, you can either completely override the rendering, or call the base method first, and then modify some aspect of the rendering. |
If you create custom WebPartVerb objects that will appear on the verbs menu of your control with the standard verbs (such as close and minimize), you must add them to the Verbs collection of your control. |
|
If you create custom EditorPart controls, to enable users to edit the custom properties on your control, you must associate them with your control by overriding the CreateEditorParts method. For an example, see the IWebEditable interface. |
|
When you create custom properties in your WebPart control, you will often want users to be able to edit and personalize those properties, just like the standard WebPart control properties, so that their settings can be saved. Add the Personalizable metadata attribute to any property that users should be able to personalize. |
Sample Data-bound WebPart Control
For a full code example that demonstrates how to create a GridView control that binds to the Northwind database, and implements the control as a WebPart control, see Data-bound Web Parts Control Example.
See Also
Tasks
Walkthrough: Creating a Web Parts Page