Connecting Controls

 Separating and encapsulating the functionality into components helps to build

a reusable framework. But most components do not exist alone but must be
linked to other elements.
The classical approach
When using the standard built-in controls of ASP.NET you will use the events
that are exposed on buttons, fields and the page and write small methods that
response to these events. Inside these event handlers you reference to other
objects directly because they are part of the page or control class or by using
their id or at runtime using a search method.
These handlers are executed by using a submit() of the HTML form element -
a post-back situation that should not happen in AJAX applications. We need a
solution on the client side of the application in JavaScript.
You can also follow this approach on the client by writing event handlers and
attaching them to the native HTML events of the HTML objects.
The drawback of these architecture is that when using complex controls the
object that exposes this event might be an inner part of the control without an
id or maybe not existing while the page is still loading.
If you want to follow this approach you can use jcl.AttachEvent. This is a
method from jcl.js include file that you can use for this purpose and that
works across the browser platforms and that allows multiple event
Even when you know all inner details of the actual control you might not want
to use that knowledge because you will give away the chance to extend or re-
implement a control without also changing all the implementations on the
The WebPart approach
With Sharepoint and the ASP.NET 2.0 WebPart Framework came another
mechanism of connecting components by using a provider-subscription
pattern. Components can register themselves for publishing (provider) or
consuming (subscription) a specific property-value. Every time when the
value of a property changes in a provider all controls that registered a
subscription for this property are informed about that.
There are some advantages for this approach:
It works even if the controls that build up a page are not known at
compile-time. (Sharepoint)
Multiple controls can easily publish the same property.
Multiple controls can easily consume the same property.
We do not need any browser- or object-specific events.
The IDs of the objects must not be known.
You see that this is a higher level approach that fits better into the problem
space of component based pages and portals and it can in addition be
combined with the eventing model of the native HTML objects.
All the available methods can be
found in the reference section of this

The Page Properties mechanism

In the framework there is a lightweight mechanism implemented that is very
similar to the WebPart approach and can be used to publish and subscribe to
named properties that are available on the page level. All the methods of this
mechanism are available through the jcl.DataConnections object.
A JavaScript Object can register itself as a provider, as a consumer or for
jcl.DataConnections.RegisterProvider(theObj, theName);
jcl.DataConnections.RegisterConsumer(theObj, theName);
To change the value of a property the Raise method can be used:
jcl.DataConnections.Raise(theName, theValue);
To receive a notification when a property has changed the GetValue method
of the registered object is called. A simple implementation may look like this:
GetValue: function (propName, propValue) {
this.value = propValue;
}, // GetValue
The names of the properties are always converted to lowercase characters so
they should only be compared by after a toLowercase conversion.
Based on this mechanism a solution for the “Back Button Problem” is also
available by using the PropHistory control.

The Connection Test Sample
This sample uses 3 kinds of controls implemented with JavaScript Behaviours
to show (and test) the implementation and usage of the client side controls
connections. There are 3 properties used in this sample (x, y and z) that can be
modified by 2 different Controls and that are visualized by a simple bar chart.

Simple Controls using page properties
PropInput Control
This control renders a HTML input element that is extended by a JavaScript
Behaviour to raises a change of its value to the property that is specified by
the "name" attribute. It is used by implementing:
<ajax:PropInput runat="server" name="x" />
This control also registers itself as a consumer to display the actual value
when changed by another control.
This control implements is a horizontal moveable rectangle that acts as a
slider. It can be used to change a property value that is specified by the
"name" attribute in the range from 0 to 100.
This control also registers itself as a consumer to display the actual value
when changed by another control.
<ajax:PropHSlider ID="PropHSlider1" runat="server" name="x" />
This control implements a simple bar chart to display multiple values. The
names of the properties are displayed below the bars. The chart itself is
implemented by using a table layout with some inner <div> elements with a
blue background color.
The names of the values can be specified by the "properties" attribute by
using a semicolon separated list of names.
The max displayable number can be specified by the "maxvalue" attribute.
This value is used as a scale factor for the display.
<ajax:PropBarChart ID="barchart" runat="server" properties="x;y;z" maxvalue="100" />
This control logs every change of any property and lists the
new value on the page inside a region. When developing a
new control that uses page properties, this little log can help a lot. 

Post a Comment

You're welcome to share your ideas with us in comments.

Previous Post Next Post