Explore ASP.NET 2.0 Web Part Infrastructure : Page 6

Connecting the Web Part to the EditorPart
With the EditorPart written, you need to tell the Web Part to use a certain editor by implementing the IWebEditable interface on the Web Part itself. The IWebEditable interface requires you to implement a method and a property.

• CreateEditorParts returns an EditorPartCollection. This is where you would instantiate the EditorPart, stuff it in a strongly-typed collection, and simply return it. This tells the framework to use the EditorParts specified in this collection in order to edit this Web Part. Here is the implementation for CreateEditorParts for this Web Part.

   EditorPartCollection IWebEditable.CreateEditorParts()
   {
      List<EditorPart> editors = new List<EditorPart>();
      editors.Add(new HtmlEditor());
      return new EditorPartCollection(editors);
   }

• WebBrowsableObject returns an object, which is simply a reference of a Web Part, user control, or server control that will be edited by the EditorWebPartCollection sent back by the CreateEditorParts method. You can implement WebBrowsableObject as shown below.

   object IWebEditable.WebBrowsableObject
   {
      get { return this; }
   }

Using the Web Part and EditorPart
With the Web Part and EditorPart set up, go ahead and add them to the master page similar to the RSSRender Web Part. Now go ahead and run the Web site, login using authenticate.aspx, and browse to default.aspx. Switch the DisplayMode to "Catalog", and add the Html Editor Web Part to WebPartZone1.

Next, switch the DisplayMode to "Edit" and add your custom HTML content and set various other properties as shown in Figure 2.

When you click OK and Logout, you will see the WinSmarts.com Web site as shown in Figure 1.

The Web site is now complete. Hooray.

But There Is More …
This article demonstrated the various concepts of the ASP.NET 2.0 Web Part infrastructure by creating the reusable framework that I used to create www.winsmarts.com. You can download the code for this entire article from the same Web site as well.

Figure 14: Error, because there is no ConnectionsZone present on the page.

You'd think I'd say, "That's all folks," like a cartoon flick after such a long article. The Web Part infrastructure offers you a rich set of features that I scraped only the surface of in this article. This article took a slightly different approach by cutting out per-user customizability. However, I presented just one implementation of the Web Parts framework. I recommend that you experiment with this project by removing the "shared scopes" from this application and watch how the behavior of this application changes with multiple users.

Also, go ahead and click on the "Connect" display mode. Chances are, you'll see a rude ugly exception as shown in Figure 14.

The exception does make sense. You didn't add a ConnectionsZone to this Web page! Wouldn't it be reasonable to expect that in any sophisticated application, you would expect to see one part of the page affect or communicate with other parts of the same Web Page?

In other words, you need a mechanism to establish communication between Web Parts.

In a future article I will explore more deeply into the details of inter-Web Part communication. Also, since the ASP.NET 2.0 Web Part framework forms the basis of SharePoint Portal Server 2007, I will write a good treatise on Web Parts in SharePoint Portal Server 2007.

Previous Page