Microsoft SharePoint 2007 Technologies

13.6 Connecting Web Parts 371

Chapter 13

tion interfaces that allowed Web Parts to communicate with one another at

run time. The great thing about this was that the Web Parts could be devel-

oped independently of one another and could ultimately share information

if they both supported the same interfaces. The interfaces provided with

the previous version of SharePoint derived from the

Microsoft.SharePoint.WebPartPages.Communication namespace and

was implemented in a provider/consumer interface pair that was used to

complete the communication sequence. For example, the

ICellProvider

interface allowed communication with other Web Parts that implemented

the

ICellConsumer interface. Keeping track of the supported connection

interface pairs proved to be quite cumbersome, and the overall communi-

cation architecture was overly complex. With Windows SharePoint Ser-

vices 3.0 and SharePoint Server 2007, Web Part connections still play a

predominant role in Web Part development; however, the connection

architecture has been revamped and now implements the standard

ASP.NET 2.0 interface, thereby removing a lot of the complexity. The

Microsoft.SharePoint.WebPartPages.Communication namespace is still

supported, but it is only recommended for backward compatibility. When

developing Web Part connections for Windows SharePoint Services 3.0

and SharePoint Server 2007, you should use the attributes and interfaces

defined in the

System.Web.UI.WebControls.WebParts namespace.

When developing connectable Web Parts, you can create a custom con-

nection interface to communicate with other Web Parts, or you can leverage

the standard interfaces provided by the

System.Web.UI.WebControls.Web-

Parts

namespace. Creating your own custom connection interface has the

advantage of being very easy to implement. However, the disadvantage is that

your Web Part can only communicate with other Web Parts that implement

the same custom interface; the Web Part will not be able to communicate

with the default SharePoint Web Parts, such as the Shared Documents Web

Table 13.3 Connection Interfaces

Connection Interface Description

IWebPartField Defines a provider/consumer interface for connecting

Web Parts using a single field of data.

IWebPartRow Defines a provider/consumer interface for connecting

Web Parts using a row of data.

IWebPartTable Defines a provider/consumer interface for connecting

Web Parts using a table of data.

IWebPartParameters Defines a provider/consumer interface for connecting

Web Parts by mapping a set of fields from one Web Part to

another.

372 13.6 Connecting Web Parts

Part. Creating Web Parts that implement the standard connection interfaces

are more complex to develop, however they have the added advantage of

being able to communicate with both custom Web Parts and the default

SharePoint Web Parts that implement the same interfaces. Table 13.3 lists the

connection interfaces available for use when developing Web Part connec-

tions. A Web Part that implements any of these interfaces can communicate

with other Web Parts that implement the same interface. For example, if you

create a Web Part that implements the

IWebPartField provider interface,

then it can communicate with another Web Part on the page that imple-

ments the

IWebPartField consumer interface.

Figure 13.63 shows an example of a Web Part, named

SendUrl, which

implements the

IWebPartField provider connection interface to provide a

URL to consuming Web Parts. It is up to the consuming Web Part how it

intends to use the URL. For example, the Image Web Part can consume the

URL provided by the

SendUrl Web Part. Figure 13.64 shows the resulting

output for the

SendUrl Web Part; the Web Part has been connected to the

image Web Part through the browser user interface. The

ConnectionPro-

vider

and ConnectionConsumer attributes enable the connections offered

by the Web Part. In our example, we use the

ConnectionProvider attribute

to enable the

SendUrl Web Part to provide data to other consumer Web

Parts. A Web Part can support both provider and consumer connections.

For Web Parts to communicate with one another, they must be able to

understand one another, and generally this means that they should imple-

ment the same connection interface. The connection interface could be a

custom interface or one of the standard interfaces provided by ASP.NET 2.0,

such as the

IWebPartField interface. However, there are times when you

will want two Web Parts that implement different interfaces to be able to

share information. In these situations, both ASP.NET 2.0 and SharePoint

provide a number of extended connections, known as transformers. For

example, ASP.NET 2.0 provides the

RowToFieldTransformer and the

RowToParametersTransformer, which allow a Web Part that has imple-

mented the

IWebPartField connection interface to communicate with a

Web Part that has implemented the

IWebPartRow connection interface, and

vice versa. The

Microsoft.SharePoint.WebPartPages namespace provides

a transformer named

ITransformableFilterValues, which allows you to

create provider and consumer Web Parts for filtering purposes. For example,

if you wanted to filter the contents of a list Web Part with a selection made in

your custom provider Web Part, you could use the

ITransformableFilter-

Values

transformer to handle the filtering. The main point here is that even

when you have Web Parts that implement different connection interfaces,

there are ways to enable communication between them.