ASP.NET 2.0 Web Part Infrastructure and SharePoint 2007 In my previous article, (“ASP.NET 2.0 Web Part Infrastructure”, Nov/Dec 2006, CoDe Magazine) I talked about the ASP.NET 2.0 Web Part framework. I made the case for the emergence of Web Part or widget-like solutions, and explained 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 take 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. | " |
In a production environment, you could restrict the number of keys you use, and then use the keys as evidence to create a tiered-level security structure based on keys to keep things clean.
| " |
SharePoint 2007 is built in ASP.NET 2.0. Thus any discussion about SharePoint 2007 starts in ASP.NET 2.0 land. In my last article, I wrote a simple example that introduced you to the major key components of the ASP.NET 2.0 Web Part framework. In that example, I wrote 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. 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. You can find the code for both my first article and the finished code for this article on my Web site at www.winsmarts.com. Towards 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 since 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.” Communication can be set up 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. Defining the Problem: the Business Requirements I wish to easily set up a Web site which serves as an RSS Reader. There are a number of such Web-based RSS Readers available such as Bloglines, NewsGator, etc. Thus the business requirements for such an RSS Reader include the following: - The RSS Reader will allow me to maintain my RSS feeds (the OPML).
- The RSS Reader will allow me to select one of the RSS feeds out of my OPML.
- When the user selects an RSS feed, I should then be able to view that RSS feed rendered on the page.
| & | | 
By: Sahil Malik
Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.
Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.
You should check out his blog at http://blah.winsmarts.com
sahilmalik@gmail.com | Fast Facts | | SharePoint works under a default locked-down mode. | |
|