Blog

Introduction

I'd like to introduce you to a new approach (pattern?) to widget communication within a dashboard style application. The basic idea is that a variable number of widgets are bound to a backend data source; each widget should be independent from the other widgets, but there needs to be a way for one widget to notify other widgets when something has changed.

Each widget is implemented as a web user control (ascx) whose contents are wrapped in an UpdatePanel for AJAX support. Since each user control is created dynamically, using delegates and events becomes difficult since event registration is not persisted in ViewState between post backs. That means that each event and its handler(s) would have to be re-wired on each user request. Additionally, the hosting page would have to have advanced knowledge of each control and what events it exposes, which leads to a tightly-coupled design. What we'd like is an approach where the widgets don't know about each other, where the widget container doesn't know about what the widgets can do, but where it's possible for widgets to send messages to each other.

Instead of using events, a different approach could be used involving interfaces to implement a dynamic publisher-subscriber alternative to events; I'll use the term "Alert" instead of "Event" to describe the messages that are passed. Alerts differ from events in that rather than registering for event notifications before the event occurs, the publishing component looks through the entire audience of possible subscribers and identifies the interested ones and calls them directly. The thought here is that classes can implement specific interfaces to identify their desire and capability to receive certain alerts. As long as there is a means to traverse the relevant objects in some sort of hierarchy, we can inspect each object to see if it should be alerted. All of this is a little abstract, so let's take a look at some code to see how this could work.

Implementation

The first thing that will be required is to create a new class that represents the arguments for an alert.

using System; 

namespace Vertigo.AlertingExample 
{ 
    public class AlertArgs 
    { 
        public static readonly AlertArgs Empty;          
        public AlertArgs() 
        { 
        } 
        static AlertArgs() 
        { 
            Empty = new AlertArgs(); 
        } 
    } 
} 

Next, the interface used to identify a class as being interested in a particular type of alert is required. Implementing this interface is analogous to creating an event handler in a class. With generics, we can create a special interface that is extensible and will allow for custom typing to uniquely identify each variation of alert.

using System; 

namespace Vertigo.AlertingExample 
{ 
    public interface IAlertable<T> where T : AlertArgs 
    { 
        void Alert(object sender, T args); 
    } 
} 

Different subclasses of the AlertArgs class can now be defined and used in conjunction with the IAlertable<T> interface to uniquely identify subscribers based on the alerts they are interested in.

Now that we have a way to define subscribers, we need a way to create and send alerts. Since IAlertable<T> is based on subclasses of the AlertArgs class, we'll just create a class that inherits from AlertArgs. To keep the usage simple, our base alerting AlertArgs class will also provide methods to send alerts.

using System; 
using System.Web; 
using System.Web.UI; 
using System.Web.UI.WebControls; 

namespace Vertigo.AlertingExample 
{ 
    public class BroadcastingAlertArgs<T> : AlertArgs where T : AlertArgs 
    { 
        public virtual void Broadcast(object sender, Page page) 
        { 
            Broadcast(sender, page.Controls); 
        } 
        public virtual void Broadcast(object sender, Control control) 
        { 
            Broadcast(sender, control.Controls); 
        } 
        protected virtual void Broadcast(object sender, ControlCollection controls) 
        { 
            foreach (Control control in controls) 
            { 
                IAlertable<T> alertableControl = control as IAlertable<T>; 
                if (alertableControl != null && alertableControl != sender) 
                { 
                    alertableControl.Alert(sender, this as T); 
                } 
                Broadcast(sender, control.Controls); 
            } 
        } 
    } 
} 

Since the alerting is occurring between user controls, we can use recursion to "walk the tree" of a control or page's control hierarchy, as seen in the Broadcast method. The concrete implementation of the Broadcast method iterates over each of the control's child controls, looking for any matches on the IAlertable<T> interface. If a match is found, its Alert method is called, passing in both the sender as well as the AlertArgs instance cast to the appropriate type. In other words, find any matching alert receivers and alert them.

Note that the class inherits from AlertArgs and has its type parameter T restricted to AlertArgs.

Example

Now that the plumbing is in place, here's an example implementation.

using System; 

namespace Vertigo.AlertingExample 
{ 
    [Serializable] 
    public class ExampleAlertArgs : BroadcastingAlertArgs<ExampleAlertArgs> 
    { 
        protected string message; 
        public ExampleAlertArgs(string message) 
        { 
            this.message = message; 
        } 
        public virtual string Message 
        { 
            get { return message; } 
        } 
    } 
} 

The ExapmleAlertArgs class inherits from BroadcastingAlertArgs<T> (and restricts its type parameter to ExampleAlertArgs) to provide specific alerting.

Note that the signature for this class is very strange! The type being declared is also used as the template type for the class it derives from. Strangely, however, this works just the way we want it to.

Now that we have our custom BroadcastingAlertArgs class, we can start broadcasting.

protected void exampleButton_OnClick(object sender, AlertArgs e) 
{ 
    // Let all the other controls know that this control changed 
    ExampleAlertArgs args = new ExampleAlertArgs("Test"); 
    args.Broadcast(this, Page); 
} 

All that's required is that we instantiate the ExampleAlertArgs class and call its Broadcast method. So now we have the alert defined and being broadcast, but no sinks. Creating a control that receives alerts only requires that a subscribing class implement the IAlertable<T> interface.

using System; 
using System.Web.UI.WebControls; 
using Vertigo.AlertingExample; 

namespace Vertigo.AlertingExample.Controls 
{ 
    public partial class ExampleControl : UserControl, IAlertable<ExampleAlertArgs> 
    { 
        public void Alert(object sender, ExampleAlertArgs args) 
        { 
            // Do something useful here 
        } 
    } 
} 

Summary

Using alerting provides a loosely-coupled approach to eventing. Since neither the broadcaster nor the alert receiver know anything about the other, new sinks can be added simply by placing them on the page with the right signature. More alerts can be defined and broadcast without affecting any pre-existing code and two controls can send alerts to each other without introducing any circular dependencies or load order issues. Also, with both the alerting and alertable controls wrapped in UpdatePanels, the screen content will be changed without visible refreshes occurring in the browser.