Developing Connected Web Parts for SharePoint Products and Technologies 2003 (Continued)

PartCommunicationInit Method
Next, you need to override PartCommunicationInit method. This method is optional and should only be used if you need to fire init events to any consumers. Below is an example of overriding this method.

public override void PartCommunicationInit()
{
   //If the connection wasn't actually formed then don't want to send Init event
   if(_rowConnectedCount > 0)
   {
      //If there is a listener, send init event
      if (RowProviderInit != null)
      {
         //Need to create the args for the RowProviderInit event
         RowProviderInitEventArgs rowProviderInitArgs = new RowProviderInitEventArgs();
               
         //Set the FieldNames
         rowProviderInitArgs.FieldList = _rowFieldNames;

         //Set the FieldDisplayNames
         rowProviderInitArgs.FieldDisplayList = _rowFieldDisplayNames;

         //Fire the RowProviderInit event.
//This basically tells the Consumer Web Part what //type of DataRow it will
         //be receiving when RowReady is fired later.

         RowProviderInit(this, rowProviderInitArgs);
      }
   }
}

PartCommunicationMain Method
Now you should override the PartCommunicationMain method. This method allows you to fire any other events for your interface, such as a new row being ready to send to the consumer. This method is where the meat of your communication code should be.

As part of the PartCommunicationMain, you will fire the RowReady event which notifies the consumer that there is a row ready to be sent. As part of the RowReady event, you need to pass the sender which is the provider object. You will also need to pass the RowReadyArgs, which has the following members: Rows, SelectionStatus. Rows are the rows you want to send back, which can include an array of rows.

SelectionStatus is the selection in the provider, which can be: New, None, or Standard. New means the new row is selected. None means that no row was selected. Standard means that a normal selection occurred. Refer to the SharePoint SDK for the same events for the other types of connections, such as IFilterProvider or IListProvider. You will find that each type sends the sender and then a customized parameter for the type of event. For example, the IListProvider needs to pass the List object as part of its parameters in the ListReady event.

The code that implements this method is in the sample application and is too long to list here. Look at the sample code to see how to implement this method.

GetInitEventArgs Method

The next method to override is the GetInitEventArgs method. This method is used by all authoring environments to query the part for all the initialization information to initially create the connection. In this method, you should pass back the correct initialization object for your particular type of connection. For example, the IRowProvider should pass back a RowProviderInitEventArgs object back. Here's the code from the sample that overrides this.

public override InitEventArgs GetInitEventArgs(string interfaceName)
{
   //Need to create the args
   RowProviderInitEventArgs rowProviderInitArgs = new RowProviderInitEventArgs();

   //Set the FieldList
   rowProviderInitArgs.FieldList = rowFieldNames;

   //Set the FieldDisplayNames
   rowProviderInitArgs.FieldDisplayList = rowFieldDisplayNames;
   
   //return the InitArgs
   return(rowProviderInitArgs);
         
}

RenderWebPart Method
Finally, you need to override the RenderWebPart method. If you want client-side communication, you will need to have script here to implement your communication. The sample included with this article does both client- and server-side communications. You will find a lot of client-side code in this method in the source code to implement the client-side communications for the Web Part.

Implementing a Consumer Web Part
Implementing a consumer Web Part is very similar to implementing a provider Web Part. The only real difference is that you implement the arguments and necessary events that are associated with consumers rather than providers. For that reason, the sample application has a consumer for which you can review the well-documented source code.

Connecting Parts Together
Once the parts are built and deployed, you can connect your parts together by just using the built-in support of SharePoint. Figure 2 shows the connecting-together of the Web Parts included in the sample application. Furthermore, the built-in Web Parts included with every SharePoint site implement connections. This means that you can work with these Web Parts and their information from your Web Parts. Again, this shows how the Web Part infrastructure allows Web Parts that do not know about each other at development time can work together at run time.

Conclusion
After reading through this text, you may think that creating connected Web Parts is not for the faint of heart. The first time you build such a part, you may find all the interfaces and methods that you have to work with daunting. Once you build your first connected set of Web Parts, however, you will definitely see how much easier it gets. And once you see the power of having Web Parts that are connected in your applications, you will wonder why you did not start building connected Web Parts earlier. Connected Web Parts make your site more dynamic and in turn make more people come back to your site to get the information they need.

About the Author
Tom Rizzo is a Group Product Manager in SQL Server. Before working in SQL Server, Tom worked on a number of Microsoft's Enterprise Servers including Exchange Server, SharePoint Portal Server and E-Business Servers. Tom is also the author of the series of MSPress books called Programming Microsoft Outlook and Exchange, now in its 3rd edition. You can reach Tom at .