In the Web Parts control set, a connection is a link or association between two WebPart (or other server or user) controls that enables them to share data. This ability to share data allows connected controls to be used in ways that exceed the functionality offered by the isolated controls. For example, if one control provides postal code data, and another control can read that data and provide local weather information based on the postal code, then the connected capability of the two controls provides more value to users. To extend this example, other controls could be created that also display information based on a postal code, such as a control with links to local news, and all these controls that can work with postal code data could share data with the single control that provides a postal code. End users of Web Parts applications can create and manage connections between all such compatible controls directly from a Web browser, using the standard connections user interface (UI) provided by the ConnectionsZone control, or using a custom UI provided by a developer.

This WebPartConnection class overview is a general statement of the basic details for creating a connection. For more on specific components and requirements involved in creating connections, see Web Parts Connections Overview, or see the reference classes and code examples mentioned in the following discussion. There are several fundamental aspects of a Web Parts connection:

Two WebPart controls. Every Web Parts connection consists of two controls. It is possible for a control to participate in more than one connection simultaneously, but every single connection consists of exactly two controls. The controls can derive directly from the WebPart base class, or they can be other server controls, including ASP.NET controls, custom server controls, and user controls. Controls that do not derive from the WebPart class, if placed in a WebPartZoneBase zone, are automatically wrapped with a GenericWebPart object at run time, which enables them to inherit from the WebPart class and function as run-time WebPart controls.

Controls residing in WebPartZoneBase zones. Both WebPart controls and any other type of server control must reside in a WebPartZoneBase zone to be able to participate in Web Parts connections (and most other Web Parts features).

Consumers and providers. In every Web Parts connection there are two controls: a provider of data and a consumer of data. The provider furnishes data to the consumer through a specified callback method that returns data in the form of an interface. (For an example of how to create and specify the callback method, see the Example section of this topic.) This callback method is known as a provider connection point. The details of this connection point (its "friendly" name, an ID, and the type of the returned interface) are contained in a ProviderConnectionPoint object associated with the provider control. The consumer receives the data through a specified method that can accept an instance of the interface. This method is known as a consumer connection point, and the details of the connection point (name, ID, and type of interface) are contained in a ConsumerConnectionPoint object associated with the consumer control.

Compatible controls or a valid transformer. For a connection to work, the consumer and provider must either be compatible (meaning that their specified connection point methods can work with the same type of interface), or there must be a WebPartTransformer object capable of translating the type offered by the provider into a type understood by the consumer.

A WebPartConnection object. For a connection to exist, there must be an instance of the WebPartConnection class that contains references to the provider and consumer controls, along with the details of their connection points. If the provider and consumer are incompatible and instead use a WebPartTransformer object to connect, the connection references the transformer.

A means of establishing the connection. After compatible consumer and provider controls have been properly designed with connection point methods and placed in a zone, and a WebPartConnection object is available, the last basic step necessary is to initiate the connection. One way this can happen is for users to create the connection through the UI. If you place an <asp:connectionszone> element on the page, and the other required components for a connection are in place, at run time a user can switch the page into connect display mode, click a connect verb on the verbs menu of either the provider or consumer, and a connection UI (based on the ConnectionsZone control) will appear. Through this UI, the user can initiate the connection. Another way to initiate the connection is to do it programmatically. In either case, whether through the UI or programmatically, the underlying method that initiates the connection is the same. The application calls the ConnectWebParts method (or the ConnectWebParts method if using a transformer) on the WebPartManager control, passing to it the provider, the consumer, and their respective connection point objects, and the method returns a WebPartConnection object.

The WebPartConnection class defines an object that encapsulates the essential details of a connection between two WebPart controls. The class consists almost entirely of properties related to the details of a particular connection. Several properties concern the consumer control in a connection. The Consumer property references the consumer control itself, and the ConsumerID property references the consumer's ID. The ConsumerConnectionPoint object, which contains the details of the consumer's connection point, is referenced by the consumer's ConsumerConnectionPoint property. The ConsumerConnectionPointID property references the ID of the ConsumerConnectionPoint object. All these consumer-related connection properties must have a value assigned to them to create a connection.

The WebPartConnection class also has several properties that relate to the provider control in a connection, and these correspond to the properties for a consumer. The Provider property references the provider control itself, while the ProviderID property references its ID. The ProviderConnectionPoint property references the ProviderConnectionPoint object, and the ProviderConnectionPointID property references the ID of the provider's connection point.

Several properties concern the state of the connection. The IsActive property indicates whether the connection is active (currently exchanging data) or inactive (still connected but not actively sharing data). The IsShared property indicates whether the connection is a shared (available to all users of a page) or a user-specific connection, and the IsStatic property indicates whether the control is static (declared in the page markup and thus permanent) or dynamic (created programmatically, meaning that it can be deleted).

The following code example demonstrates how to create a simple connection between two WebPart controls. The example demonstrates three ways of forming a connection: declaratively, by placing tags for the connection in the markup of the Web page; programmatically, by creating the connection in code; and through the UI, by placing a ConnectionsZone control on the page, which enables users to establish a connection.

The code example has four parts:

A user control that enables you to change the Web Parts display mode on a page.

Source code for an interface and two WebPart controls acting as the provider and the consumer for a connection.

A Web page to host all the controls and run the code example.

An explanation of how to run the example page.

The first part of this code example is the user control that enables users to change display modes on a Web page. Save the following source code to an .ascx file, giving it the file name that is assigned to the Src attribute of the Register directive for this user control, which is near the top of the hosting Web page. For details about display modes and a description of the source code in this control, see Walkthrough: Changing Display Modes on a Web Parts Page.

The second part of the code example is the source code for the interface and controls. The source file contains a simple interface named IZipCode. There is also a WebPart class named ZipCodeWebPart that implements the interface and acts as the provider control. Its ProvideIZipCode method is the callback method that implements the interface's only member. The method simply returns an instance of the interface. Note that the method is marked with a ConnectionProvider attribute in its metadata. This is the mechanism for identifying the method as the callback method for the provider's connection point. The other WebPart class is named WeatherWebPart, and it acts as the consumer for the connection. This class has a method named GetZipCode that gets an instance of the IZipCode interface from the provider control. Note that this method is marked as the consumer's connection point method with a ConnectionConsumer attribute in its metadata.

For the code example to run, you must compile this source code. You can compile it explicitly and put the resulting assembly in your Web site's Bin folder or the global assembly cache. Alternatively, you can put the source code in your site's App_Code folder, where it will be dynamically compiled at run time. This code example uses dynamic compilation. For a walkthrough that demonstrates how to compile, see Walkthrough: Developing and Using a Custom Server Control.

The third part of the code example is the Web page. Near the top are the Register directives for the user control and the custom WebPart controls. Because the example assumes dynamic compilation of the controls, the source code for the controls should be in an App_Code subfolder; the Register tag in the page references only an arbitrary tag prefix and the namespace of the controls. The custom WebPart controls (the provider and consumer) are declared within the Web page's <asp:webpartzone> element, inside a <zonetemplate> element.

The page provides three ways to form a connection between the custom controls. The first method is declarative. In the markup for the page, a <StaticConnections> element is declared, and within that is an <asp:WebPartConnections> element, with the various consumer and provider details of the connection specified as attributes. This is one way to create a connection, by declaring it directly in the Web page, specifically within the <asp:WebPartManager> element. Because of this static connection, a connection between the two custom controls is created immediately the first time the page loads.

A second method for forming a connection between the controls is provided by the <asp:connectionszone> element in the page. If a user switches a page into connect display mode at run time, and clicks a connect verb on one of the custom controls, the <asp:connectionszone> element automatically renders the UI for creating a connection.

The page also demonstrates a third way of creating a connection, which is to do it programmatically. In the Button1_Click method, the code creates a ProviderConnectionPoint object for the provider control, and retrieves its connection point details by calling the GetProviderConnectionPoints method. It carries out a similar task for the consumer control, calling the GetConsumerConnectionPoints method. Finally, it creates the new WebPartConnection object by calling the ConnectWebParts method on the WebPartManager control.

After you load the Web page in a browser, the first connection already exists because it is declared within the <StaticConnections> element. Enter some text in the ZIP Code Provider control, and it will be displayed in the consumer control. Next, disconnect the two controls. Using the Display Mode drop-down list control, change the page to connect display mode. Click the verbs menu (represented by a downward arrow in the title bar) for each of the WebPart controls, and notice that each has a Connect option. This is a connect verb, which appears in the verbs menu only when the page is in connect mode. Click the connect verb on one of the controls, and the connection UI provided by the ConnectionsZone control appears. Click the Disconnect button to end the static connection between the controls. Use the Display Mode control to return the page to browse mode. Try to enter some new text in the provider again, and note that because the controls are disconnected, the text fails to update in the consumer control.

Next, use the same method as above to switch the page into connect display mode again. Click a connect verb on one of the controls. Click the Create a Connection link, and use the UI provided by the ConnectionsZone control to create a connection between the controls. This is the second method for creating a connection. Note that as soon as the connection is formed, the last string you entered in the provider control (that failed to appear because the controls were disconnected) suddenly appears in the consumer, because the connection has been recreated. Click the Disconnect button to end the current connection that you just created. Return the page to browse mode. Enter some new text in the provider to demonstrate that the text is not updated, and that the controls are again disconnected.

Return the page to connect display mode. Instead of clicking a connect verb, click the Connect WebPart Controls button, which illustrates the third method of forming a connection. This approach connects the controls programmatically in one simple step without having to use the ConnectionsZone control. Note that as the connection is created, the last string you entered in the provider suddenly appears in the consumer control.