Managing Multiple Connections Within a Custom Web Part

If you have written custom Web Parts, you may have encountered Web Part connections. In short, the System.Web.UI.WebControls.WebParts namespace provides functionality that lets you connect your custom Web Part to another custom Web Part—or any of the "out-of-the-box" Web Parts provided by Windows SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS). In a few lines of code you can enable your Web Part to share data with other Web Parts. To me this is one of the truly fantastic features of ASP.NET and the Web Part framework, because it puts the power of developing applications directly in the hands of those who know the data best: the end users. Web site creators can connect Web Parts using a menu-driven system (see Figure 1).

Figure 1. Menu-Driven Connections: End users can connect Web Parts using SharePoint's menus.

At its simplest, a Web Part connection requires two participating Web Parts: a consumer and a provider. The consumer pulls a value (or series of values) from the provider, and the two Web Parts communicate via an interface. The .NET Framework 2.0 and later includes several interfaces that you can use to implement a connection between Web Parts. Examples include IWebPartField, IWebPartRow, and IWebPartTable. In addition, you can create custom interfaces to define data that two Web Parts may need to share. Using a custom interface provides more control over how the Web Parts communicate.

A simple interface to describe data shared between two Web Parts might look something like this:

' In VB
Public Interface IFile
    Property FileID() As Integer
End Interface


// In C#
public interface IFile
{
   int FileID
   {
      get;
      set;
   }
} 

The "Chained" Web Part Scenario

Figure 2. Web Part Connection Scenario: In this scenario, all three Web Parts act as both consumers and providers.

If you want to design a Web Part that can act as both a consumer and as a provider within the Web Part connections framework, then you need to be mindful of how, when, and where you make requests from one Web Part to another. Imagine this not-uncommon scenario. You have a single Web Part that displays data from an external data source of some kind. This Web Part needs to be able to consume a unique ID to retrieve the data. However, it also needs to be able to provide both the ID and other data—which could potentially be connected to other Web Parts (see Figure 2).

To achieve such dual-connection Web Parts, you need to implement the custom interface in all Web Parts that participate in the chain (unless a particular Web Part is expected to act only as a consumer). In addition, you must implement code such as that shown in Listing 1 (VB) or Listing 2 (C#).

In Listing 1 and Listing 2, the FileID property comes from the IFile interface implementation described above. The important elements here are the methods decorated with ConnectionProvider and ConnectionConsumer attributes. The former returns the current instance of IFile (e.g. this Web Part), while the latter sets the value of a private variable representing the instance of IFile returned from the provider. If these are not present then SharePoint will not detect the Web Part connection.

TAGS: