Are you looking to connect two custom SharePoint web parts to each other? Did you know there is more than one way to accomplish this? From what I've seen and heard from the developers around me is that most only know of one way, and in this post I'd like to discuss and compare this commonly known way with 2 other ways that are less known…

Approach #1: SharePoint Web Part Infrastructure Connections

This first approach to connectable web parts is by far the most widely known in the SharePoint community. Essentially, you can tap into the SharePoint Web Part infrastructure's connection interfaces to pass and receive data from one web part to another. The setting up of the connection is done through the UI, simply upload the web part(s), edit, and connect:

MSDN Walkthrough: http://msdn.microsoft.com/en-us/library/ms469765.aspx

Approach #2: Client Side SharePoint Web Part Infrastructure Connections

Similar to approach #1, but it supports a client side (javascript) connection without the need to post back to the server when actions occur. If extreme usability is important, going with this approach is worth looking at, but developer beware, it takes more than a "Hello World" to implement client side connections. Here's a good write-up though: http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=20

Approach #3: Client Side Callbacks

Using client side callbacks to connect web parts is not a commonly known or understood method, yet it remains one of my favorite and most frequently used techniques. The basic premise behind the technique is the Consumer web part drops a javascript method onto the page that can callback to the server to execute .NET code. Then, any other web part on the page, even a content editor web part (CEWP), can call that method and pass a parameter into that method, and in essence "Provide" data and "Connect" the two web parts together. Actually, any HTML object on the page can "Provide" data, since it's just javascript we're dealing with. It doesn't even have to be a web part!

For example, the screen shot below shows a data grid, and when a row in the data grid is selected, the "Item Details" web part shows the full details for that row:

Essentially, all that happens is when a user clicks the row in the data grid, a javascript method is called which was put onto the page by the Item Details web part. That Item details web part, on the client side, calls back to the server and executes a stored procedure and returns the result of that call and updates a DIV with that result.

1. 1 - Javascript method dropped on page by "Consumer" web part is called by the "Provider" web part or sundry html object. (in this case when the user clicks a row in the grid view)
2. 2 - "Consumer" web part calls back to server
3. 3 - Web server requests some data
4. 4 - SQL box returns some data
5. 5 - "Consumer" web part updates a div on the page with the result of the callback from the web server

What's great too about this method is it is all ajaxically performed, and in my example I load up a progress bar while the callback is executing:

Here's a good write up to help you get started with client side callbacks: http://www.beansoftware.com/asp.net-tutorials/client-side-callback.aspx

Phil's Recommendation When to use Which

If you are…

• Going to need to allow your end users to setup the "Connections" in the browser:
  
  Approach #1 if you don't care about post backs, and Approach #2 if you do…
  
  
  
• You want an AJAX user experience and your end users won't be configuring the connections themselves:
  
  Approach #3 (much easier than #2 to implement)

Cheers!

Phil