This topic contains instructions for building and running the data-bound control, for which a complete code example is provided in the topic Data-bound Web Parts Control Example. The code example demonstrates how to create a custom server control that binds a control to a data source, but also inherits from the WebPart class so that it can participate in Web Parts applications. This topic gives the related information you will need to compile the code example and configure an ASP.NET Web application to run the control as a Web Parts control.
Compiling the WebPart .
To dynamically compile the data-bound WebPart control
In the root folder of your Web application, create a folder named App_Code.
Obtain the source code for the custom data-bound WebPart control from the topic Data-bound Web Parts Control Example. Place the source code file in the App_Code folder. The name of the file does not matter because you are using dynamic compilation, but the file must have the appropriate extension for the language you are using (such as .cs or .vb).
Using the Control in a Web Parts Application
Configuring an application to use Web Parts requires only that you have an ASP.NET Web site that can authenticate individual users, and a database enabled to handle application services including personalization. For this example (because it uses a data-bound control), you also need to create a connection string in the Web.config file that enables the data source to connect to the Northwind sample database. After the application is configured, in every Web Parts application you need to add a control and at least one control to each Web page that will host the WebPart and server controls in your Web Parts application. The second procedure below demonstrates how to add these controls, and to carry out the other steps needed to prepare the page to run the data-bound control.
To configure an ASP.NET application to run Web Parts controls
Ensure that you have an ASP.NET Web application that is configured to recognize individual users. If you need directions on how to create such a site, see or .
Ensure that you have a configured personalization provider and database. Web Parts personalization is enabled by default, and it uses the SQL personalization provider () with the Microsoft SQL Server Express (SSE) edition to store personalization data. This topic Microsoft.
Create a connection string so that the data-bound control can connect to the sample Northwind database. To run the example, you will need access to the sample Northwind database provided with SQL Server. If you do not have the Northwind sample database installed, you can download scripts to create and install the database from the
Microsoft Download Center.
A recommended approach for connection strings is to place them in the Web.config file for your application. For more information about configuration files, see . The following code example shows a connection string in the Web.config file, connecting to a local instance of Northwind running on SSE. Note that the single quotation marks (') that would normally delimit the path to the database file are rendered as entities ("). This is required because Web.config is an XML file.
In the <system.web> section of the Web.config file, add a <webparts> element. This is not required for every Web Parts application, but certain features of Web Parts applications must be configured in this section if you want to use them. The sample data-bound WebPart control is enabled for exporting a configuration file containing its state and property data. Because the export feature is disabled by default in Web Parts applications, you must enable it in the <webParts> section. Add an enabledExport attribute to the <webParts> element and set its value to true, as in the following code example.
Save and close the Web.config file.
To prepare a Web page to host Web Parts controls
Create a user control that will enable users to switch between the available Web Parts display modes on the Web page. This control and the next step are not required to run the data-bound Web Parts control, but this is a feature that is useful on many Web Parts pages. In an editor, paste the following code for the user control, and save the file in your Web application's root folder with the name Displaymodemenucs.ascx or Displaymodemenuvb.ascx (depending on which language you are using).
Create a new ASP.NET page to host the custom WebPart control and the other controls. Add a Register directive to the page, just below the Page directive, to register the user control you just created. The directive contents depend on which language you are using, and should look like the following example.
[Visual Basic]
[C#]
Now add a Register directive for the custom WebPart control. Because this topic uses dynamic compilation, you do not need to add an Assembly attribute to the directive. Just below the previous directive in the file, add another Register directive, assign an arbitrary string to its tagprefix attribute, and assign the namespace of the custom control to the namespace attribute, again depending on the language you used, as in the following example.
[Visual Basic]
Add an <asp:webpartmanager> element to the page, just inside the <form> element, as shown in the following code example. A WebPartManager control is required on every page that uses Web Parts.
Declare the user control for switching display modes, just after the <asp:webpartmanager> element. How you declare the control depends on which language you are using, as in the following code example.
[Visual Basic]
After the user control, add a table with one row and two columns, to structure the layout of the controls on the page. The table markup should look like the following code example.
Within each set of <td> tags, add an <asp:webpartzone> element. A zone that derives from the class is required to contain WebPart controls and enable them to have full Web Parts functionality. The markup for the first zone should look like the following code example.
The markup for the second zone should look like this.
Declare the custom data-bound WebPart control in the first zone, between the <zonetemplate> tags, as shown in the following code example. Note that the markup uses the tag prefix defined in the Register directive for the control, as well as the class name for the custom control. Also note that a custom property defined in the control--
ConnectionString--appears as an attribute with the connection string from the Web.config file assigned to it. This approach enables page developers to determine what connection string to use for the control. The markup should look like this.
For comparison purposes, declare an ordinary calendar server control in the second zone, between the <zonetemplate> tags. Because you are placing the control in a WebPartZone control, it will behave like a WebPart control at run time. For details on using server controls in Web Parts applications, see Using ASP.NET Server Controls in Web Parts Applications. The markup should look like the following code example.
Save and close the page. You are now ready to run the page and test the custom WebPart control. The completed code for the page should look like the following code example.