One of the MOSS 2007 features that ASP.NET developers often miss when writing a custom solution for WSS 3.0 is the QueryString (URL) Filter web part. We often use the query string to define the filter for displaying lists or forms. This web part gives users the flexibility to define the query string key value without affecting the functionality of the solutions.
For some of the custom solutions we have built for WSS 3.0, we have implemented our own QueryString Filter web part to provide similar functionality and flexibility. With this web part, we can easily pass information from query string to a different web part located on the same page. For example: we need to list all customers who lives in 30319 zip code. In this case, we will have the QueryString Filter web part to pass ‘30319’ from the query string to the customer list web part. But how do the web parts pass this information? The data transfer between web parts is done using web part connections. When using web part connections, we have to define which web part is going to be the provider and which one is going to be the consumer. In our example, the QueryString Filter web part is the provider and the Customer list web part is the consumer.
The example we provided is pretty straight forward. We only need to pass one value, the zip code, from the query string to the consumer web part. What happens if we need to use multiple query string keys? Can a single web part be the consumer of multiple web part connections?
The answer is 'yes'. When a web part is acting as the consumer of a web part connection, we define a method that will consume the passed information and mark this method with the [ConnectionConsumer] attribute. Check the MSDN reference to this attribute. Note that there are several constructors available for this attribute. Also note the remarks on the reference page:
A consumer control can have multiple methods marked with the ConnectionConsumerAttribute metadata element. In this case, the consumer would have multiple connection points, and each instance of the ConnectionConsumerAttribute element should specify a unique ID value for the associated connection point, so that the consumer's connection points can be distinguished.
When dealing with a single web part connection, the only property of this attribute you need to define is the display name property and the .NET Framework will take care of the rest. However, when dealing with multiple web part connections, you have to specify unique IDs for each web part connection the control is going to consume. You can pass the ID value as the second parameter when you declare the ConnectionConsumer attribute. For example:
[ConnectionConsumer("Quote ID", "QuoteIDConsumer")]
public void SetQuoteID(string quoteID)
[ConnectionConsumer("Store ID", "StoreIDConsumer")]
public void SetStoreID(string storeID)
Note: the code above allow the web part to consume two different connections, one for quote ID and the other one for store ID.
Then in the ASP.NET page where the web parts are located, when you declare the web part connection objects in the <WebPartManager> -- <StaticConnections> section, you need to set the ConsumerConnectionPointID attribute and its value should match you unique ID that you have specified in the consumer web part earlier.
For example:
<asp:WebPartManager ID="WebPartManager1" runat="server" Personalization-Enabled="false">
<StaticConnections>
<asp:WebPartConnection ID="_connection1" ConsumerID="WebPartConsumerID1"
ProviderID="QueryStringFilter1" ConsumerConnectionPointID="QuoteIDConsumer">
</asp:WebPartConnection>
<asp:WebPartConnection ID="_connection2" ConsumerID="WebPartConsumerID2"
ProviderID="QueryStringFilter2" ConsumerConnectionPointID="StoreIDConsumer">
</asp:WebPartConnection>
</StaticConnections>
</asp:WebPartManager>
If you use the consumer web part in SharePoint, in Page Edit Mode you will see the following when setting the web part connections for that web part:

In this example, a consumer web part is configured to consume a query string value from two separate Query String Filter Providers simultaneously.