Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

ASP.NET 2.0 Web Part Infrastructure and SharePoint 2007

Find out how to make your Web Parts communicate with each other and share data.


advertisement
n my previous article, "ASP.NET 2.0 Web Part Infrastructure" I wrote about the ASP.NET 2.0 Web Part framework, making the case for the emergence of Web Part or widget-like solutions, and explaining the support for Web Parts in the ASP.NET 2.0 framework. However, I stopped short with a teaser into connecting these Web Parts with each other and where this story fits in with SharePoint 2007.

In this article, I intend to cover the rest of that ground. As I indicated in my last article, SharePoint 2007 is built on ASP.NET 2.0. In this article I intend to move the discussion from ASP.NET 2.0 to SharePoint 2007. I will demonstrate Web Part connections, and how all that I have discussed in these two articles ties into writing Web Parts for SharePoint 2007.

SharePoint 2007 is built in ASP.NET 2.0. Thus any discussion about SharePoint 2007 starts in ASP.NET 2.0 land. My last article contained a simple example that introduced you to the major key components of the ASP.NET 2.0 Web Part framework—a simple Web site that demonstrated key concepts such as the GenericWebPart, Web Part catalogs, personalization, and writing custom editors for the Web Parts. However, I stopped short at Web Part connections, and I really didn't talk much about SharePoint 2007.

In this article I intend to continue the journey forward, discuss Web Part connections, and finally finish at writing and deploying custom Web Parts in SharePoint 2007.

If you haven't had a chance to read my last article, I strongly suggest that you start there or this article won't much too much sense. You can find the code for both my first article and the finished code for this article on my Web site.

Web Part Connections
Picking up from where I left off in the last article, I will continue to enhance the code I have already written. Toward the end of my last article, I invited you to attempt to set the display mode of the WebPartManager to Connect. In response you saw an exception as shown in Figure 1.

 
Figure 1: Error from last article because there is no Connections Zone on the page.
This exception was reasonable to expect because I haven't yet added a ConnectionsZone to my Web pages. Since all my zones are in the SiteMaster.master file, open the master page and add the connections zone as shown below:

<asp:ConnectionsZone ID="ConnectionsZone1" runat="server"/>

With this new zone added to the master page, try selecting the Connect display mode once again. You no longer receive the error. But what does the connect verb do, and what can you use this zone for?

This zone will provide you with a UI allowing you to connect different Web Parts with each other. In other words, if two Web Parts on the same page wish to communicate with each other, and are able to communicate with each other, you can set up this communication using the connections zone.

That is a mouthful. But I just covered two very interesting points.

The first point is: "If two Web Parts are able to communicate with each other…" The obvious question here is: "What qualifies two Web Parts as being able to communicate with each other?" Two Web Parts can communicate with each other as long as they speak the same language—the same language being a common interface, as you will see shortly. In case they do not understand a common interface, they can still communicate with each other as long as there is a transformer in the middle. A transformer simply performs the task of translating between two Web Parts that understand communication, but do not speak the same interfaces.

The second important point is: "…being able to set up this communication using a connections zone." You can set up communication at run time using the connections zone. You also have the option of setting up communication statically at design time between various Web Parts using the <StaticConnections> element inside the WebPartManager. For the purposes of this article, I will focus on the more interesting way of setting up communication, which is at run time using the connections zone.

Similar to the last article, the best way to learn to swim is to dive right in. Let me first present you with a practical problem to solve, and in the process of solving this problem I will illustrate the various concepts pertinent to Web Part communication and Web Parts in SharePoint 2007.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap