Manipulating Web Parts in ASP.Net 2.0

In my last article, I introduced web parts to you, explained how to implement them in an ASP.Net application, and how to modify their default behavior and properties. This article will explain how you can allow end users to edit the web parts on their page(s), as well as interconnecting multiple web parts on one page.

Contributed by Justin Cook
Rating:

/ 11
December 05, 2005

Rate this Article:
MEH MEH++

SEARCH ASP FREE

Editing Web Parts

By now you should be pretty comfortable with installing web parts in your web applications. If not, you’ll need to go back to my first article on the subject, located here. You should have a basic page up and running with a couple of web parts, and if you followed the tutorial, they’re most likely based on user controls. Here’s the final code we developed in the last tutorial:

<%@ register tagprefix=”jc” tagname=”Weather” src=”weather.ascx” %>
<%@ register tagprefix=”jc” tagname=”Stocks” src=”stocks.ascx” %>
<%@ page language=”C#” %>

<html>
<head>
<title>webparts tutorial</title>
</head>
<body>
<form runat=”server” id=”Form1”>
  <asp:WebPartManager runat=”server” id=”myWebMgr” />
  <asp:WebPartZone runat=”server” id=”zone1” PartChromeType=”Title”>
  <CloseVerb text=”hide” />
  <minimizeverb text=”shrink” />
  <PartStyle BackColor=”#CCC” />
  <ZoneTemplate>
<jc:Weather runat=”server” id=”myWeather” />
<jc:Stocks runat=”server” id=”myWeather” />
</ZoneTemplate>
  </ asp:WebPartZone>
</form>
</body>
</html>

This will display the weather and stock user controls, but with all the added functionality and visual characteristics of a standard web part. The functionality includes being able to minimize, close, and move a web part within a page.

All visual characteristics are of course customizable, by both the developer and the end user. In the last article, we saw only how the programmer determines the visual aspects. But now I’ll show you how the end user can modify these, at run time. They can also make modifications to more than just the display; they can modify some of the behavior as well. Here’s the code you’d need to add to allow users to make their edits.

<asp:EditorZone runat=”server” HeaderText=”Modify Settings”>
<ZoneTemplate>
  <asp:AppearanceEditorPart runat=”server” />
  <asp:BehaviorEditorPart runat=”server” />
  <asp:LayoutEditorPart runat=”server” />
  <asp:PropertyEditorPart runat=”server” />
</ZoneTemplate>
</asp:EditorZone>

You could further customize the actual rendering of the EditorZone by modifying the properties of the header and instruction text, as well as many other visual properties, but that is purely aesthetics, so I’ve trimmed down the example to purely functional pieces. What we’re most concerned with is the actual functionality provided by the four possible editor parts.

Here’s an explanation of what each one does. (Note: not all need to be loaded; I simply placed them all in the code for the sake of explanation)

Appearance Editor Part: modifies visual aspects such as width, title, text direction and border settings.
Behavior Editor Part: determines whether personalization is supported, as well as editing and minimization.
Layout Editor Part: determines frame style (normal vs. minimized), which zone the part is in, and the placement index within the specified zone.
Property Grid Editor Part: custom properties. For this to show up, the web part must have public properties with the Personalizable and WebBrowsable attributes set.

So once you’ve set up the Editor Zone and the contained template, each web part on the page will have an ‘Edit’ link attached to the list of options. Once clicked, the editor web part will appear exactly where you’ve coded it on the page. The default “Windows” buttons will appear in the footer, “OK”, “Apply”, and “Cancel”. Once again Microsoft has taken another step towards making the web a comfortable extension of what the vast majority of people are comfortable with in their operating system. This is a smart usability tactic.

So once the user has made a change to their web parts’ settings, what needs to happen next? In other words: what do we as programmers have to develop to retain and restore each persons’ custom settings? Nothing. Absolutely nothing. If we’ve defined the personalization data store (next article), the personalization engine of the ASP.Net framework takes care of absolutely everything for us. Now you understand why I said web parts are going to be huge!

The Web Part Catalog

The driving factors behind web parts are personalization and customization. With that in mind, there are going to be two very common scenarios with pages containing web parts:

You have ten available web parts, but only five are suitable for general consumption. The other five are more specialized, so you leave them hidden by default, so that people only have to add them if they decide they’re relevant.
People ‘close’ a web part or two. Then later, they decide they’d like to have them both.

Microsoft has made it very simple to take care of these scenarios from the developer’s perspective as well as the end user. They created the concept of the ‘Catalog Zone’, where information about all available web parts – including ones closed by the users – is stored. At run time, a user can simply click ‘Personalize this Page > Add Web Parts To This Page’ to bring up the catalog.

Of course we can’t get away with no code whatsoever, but it’s pretty minimal nonetheless. Here is all the code necessary to enable the functionality I just mentioned:

<asp:CatalogZone runat=”server” HeaderText=”Customize this page”>
<ZoneTemplate>
  <asp:PageCatalogPart runat=”server”
title=” your parts” />
  <asp:declarativeCatalogPart runat=”server”
title=”also available”>
   <webpartstemplate>
    <jc:mathPart runat=”server” id=”otherPart1” />
    <jc:dogPart runat=”server” id=”otherPart2” />
</webpartstemplate>
  </asp:declarativeCatalogPart>
</ZoneTemplate>
</asp:CatalogZone>

So the PagePartCatalog is the placeholder for any default web parts that have been removed, or ‘closed’, by the user. The DeclarativeCatalogPart is where you manually specify any additionally available web parts, which will be instantiated only after a user adds them to the page.

And of course, this would not be a full Microsoft offering if we weren’t able to customize the rendering to our liking. Here are the available display properties to modify:

CatalogItemStyle
HeaderStyle
HeaderVerbStyle
InstructionStyle
PartLinkStyle
VerbStyle

So go ahead, set up a catalog, modify its display, Microsoft has made it incredibly easy to do so. The fun part comes now, as we try to communicate data between separate web parts.

Web Part Connections

To allow separate web parts on the same page to communicate with each other, you need to utilize the services of the Web part connection object. This object creates and maintains a channel of communication between two Web parts, one that is the provider, and the other the consumer. Any changes in data from a provider will be instantly updated in the consuming web part.

To set up a Web part connection, you need at least two web parts that define connection points. Connection points are possible connections for a web part that can act as a provider or a consumer. The provider implements an interface defining which properties, events, or methods that the consumer can use. This is called the communication contract.

To create a provider connection point within a web part, you need to create a function that returns an instance of the class, and tag it with the special attribute: “ConnectionProvider”. If we had a web part called CustomerInfo that displayed information about a specific customer, you could enable a connection point with the following code:

public int CustID
{
get { return custID; }

[ConnectionProvider(“CustIDProvider”, “CustIDProvider”)]
private CustomerInfo ShareCustomerInfo()
{
Return this;
}

And then we could have a web part called CustomerTickets responsible for grabbing the ID of the currently displayed customer, fetching any support tickets processed for them, and displaying them. Within that web part, we’d need the following code for a connection point:

[ConnectionConsumer(“CustIDConsumer”,” CustIDConsumer”)}
private void DisplayTickets(CustomerInfo cust)
{
this.custID = cust.custID;
// following code to retrieve info from DB, display
}

Then we could throw them both onto our page by registering the tags, and inputting the following code:

<jc:CustomerInfo runat=”server” id=”cust”
title=”Current Customer Information” />
<jc:CustomerTickets runat=”server” id=tick”
Title=”Support Tickets” />

Then we hook them together with the following (within the WebPartManager block):

And that is that! Now any time you change the customer ID in the Current Customer Information web part, the updated support ticket information is automatically retrieved and displayed in the support ticket information web part.

Conclusion

These two articles should provide enough information to allow you to get a good grasp on the usage of web parts, both simple and advanced. I must say, I don’t think Microsoft could have made it any easier for us!