Developing Connected Web Parts for SharePoint Products and Technologies 2003
Connect your Web Parts and take your SharePoint site development to a whole new level.
by Tom Rizzo

For This Solution: Windows Server 2003; Windows SharePoint Services, Beta 2 or better; Microsoft Office SharePoint Portal Server 2003, Beta 2 or better; Visual Studio .NET 2002 or 2003 (C# example given)

Having different Web Parts interact on your site allows you to build truly dynamic sites. For example, you may want to have one Web Part provide more details when a user clicks on an item in another Web Part. To provide this advanced functionality, Windows™ SharePoint Services (and, as a result, Microsoft® Office SharePoint Portal Server 2003) support connecting Web Parts together in new and interesting ways. This article will teach you how to connect your Web Parts and take your SharePoint site development to a whole new level.

A Web Part connection allows your Web Part to either consume or produce information that works with other Web Parts on the same page. For example, you may have one Web Part which displays a list and another which displays the details of the currently selected row from that list. However, you do not want your Web Parts to be dependent on each other since a user may remove one or the other of the Web Parts. This is where you would use Web Part connections to wire together your Web Parts so that they could work together or be standalone if necessary

Implementing connected Web Parts, as you will see, is straightforward. There are different interfaces that you can use in order to do your part-to-part connections in SharePoint Services. Once you override these methods, you have a connected Web Part. SharePoint Services will take care of the rest for you, such as providing user interfaces for connecting Web Parts and also the underlying communication between Web Parts.

Building Your First Connected Web Part
Building your first connected Web Part starts with figuring out where you want the connection to occur. You can implement your connection interfaces on the client, on the server, or in both locations. This gives you the flexibility to implement your interfaces wherever you want your code to run. If you do not want postbacks to the server, you should leverage client-side interfaces. In the sample code included with this article, you will find Web Parts that implement both client-side and server-side connections. This sample is shown in Figure 1.

Before diving into the code to build a connected Web Part, we first must look at the interfaces that you can implement for your connectivity. The Web Part infrastructure provides a number of interfaces that you can implement depending on the functionality you want in your Web Part. Table 1 shows the interface pairs and the functionality these interfaces provide. Please note that in the browser, you can only connect using certain interfaces and only to other Web Parts on the same Web page. With FrontPage 2003, you get a richer experience since FrontPage can connect Web Parts using more interfaces, and can also connect Web Parts across Web pages, which the browser cannot do.

Once you have decided which interfaces you want to override for Web Part communications, you just need to implement the interface, implement two events, and override six methods. The first step is to tell your class that you want to implement your interfaces. The following line of C# code shows how to implement an IRowProvider interface in your class.

public class RowConWP : WebPart, IRowProvider

Implementing the Events for Your Web Part
The next step is to declare the relevant events for the type of Web Part we are building. IRowProvider requires two events to be implemented. One is used to initialize the field names for the consumer and the other is to tell the consumer that a row of data is ready. Here is the code to declare these two events.

//RowProviderInit Event
public event RowProviderInitEventHandler RowProviderInit;

//RowReady Event
public event RowReadyEventHandler RowReady;

EnsureInterfaces Method
The next step is to override EnsureInterfaces method. This method tells the Web Part architecture what interfaces you will be using by calling the RegisterInterface method in your EnsureInterfaces method.

public override void EnsureInterfaces()
{
//Register the IRowProvider interface
RegisterInterface(

//InterfaceName: Friendly name of the interface
"MyRowProviderInterface_WPQ_",   

//InterfaceType: The type of the interface   
"IRowProvider",                           

//MaxConnections: sets how many connections can
   //be formed on this interface
WebPart.UnlimitedConnections,

//RunAtOptions: where the interface can be run
      ConnectionRunAt.ServerAndClient,          

//InterfaceObject: reference to the actual
   //object that implements this interface
this,

//InterfaceClientReference: for client-side connections, a
   //string that is used as the identifier for the client-side
   //object that implements this interface
   "RowProviderInterface_WPQ_",             


//MenuLabel: a general label for the interface
   //(used in Authoring Connections)
   "MyRowProvider",                         

//Description: an extended explanation of the
   //interface (used in Authoring Connections)
   "Just a simple IRowProvider");           
}

CanRunAt Method
The next step is to override the CanRunAt method. This method is where you tell the Web Part Page environment in SharePoint Services where your connections for your Web Part will be. This can be on the client, on the server, or both. Please note, though, that you cannot have a client connection work with a server connection, or vice versa.

public override ConnectionRunAt CanRunAt()
{
//This Web Part can run on both the client and the server
   return ConnectionRunAt.ServerAndClient;
}

PartCommunicationConnect Method
The next step is to override the PartCommunicationConnect method. This method is called by the infrastructure to inform the Web Part that it has been connected, and to pass along relevant information such as which part it has been connected to. As part of this method, you should keep track of where the interface can run, create your UI controls, and verify that the connection is valid. Table 2 lists the parameters for the PartCommunicationConnect method.

An example of overriding this method is shown below. This code makes sure that the Web Part attempting to connect to your provider is the client you created. If not, you just ignore the connection.

public override void PartCommunicationConnect(string interfaceName,
         WebPart connectedPart,
         string connectedInterfaceName,
         ConnectionRunAt runAt)
{
//Check if this is my particular interface
   if (interfaceName == "MyRowProviderInterface_WPQ_")
   {
      //Keep a count of the connections
      _rowConnectedCount++;
   }

   //Check to see if this is a client-side part
   if (runAt == ConnectionRunAt.Client)
   {
      //This is a client-side part
      _runAtClient = true;
      return;
   }
         
   //Must be a server-side part so need to create the Web Part's controls
   EnsureChildControls(); 
}