Intelligent Web Applications with AJAX

By Victor Rasputnis, Anatole Tartakovsky, Igor Nys	Article Rating:
October 9, 2006 12:00 PM EDT	Reads:	28,091

Related
Print
Email
Feedback
Add This
Blog This

Data-Bound Checkbox Control
As an illustration of element behavior, we'll construct a custom data-bound checkbox. The rationale behind building such a control is that a standard HTML checkbox has several noticeable shortcomings:

It requires application code to map the value of the "checked" attribute into business domain values, such as "Y[es]"/"N[o]", "M[ale]"/"F[emale]", etc. The HTML checkbox uses "checked" contrary to many other HTML controls using "value".
It requires application code to maintain the state of the control (modified versus not modified). This is actually a common problem with all HTML controls.
It requires application code to create an associated label that should accept click and change the state of the checkbox accordingly.
The standard HTML checkbox doesn't support "validation" events to allow the canceling of a GUI action under certain application conditions.

To settle on a syntax, let's say that a sample usage of the control we are building could look the following way:

In addition, our control will support the cancelable event onItemChanging and the notification event onItemChanged.

Custom Tag Definition Structurally, a custom tag is a file with an HTC extension that describes its properties, methods, and events between <PUBLIC:COMPONENT> and </PUBLIC:COMPONENT>.

To define a custom CHECKBOX tag, we create a file checkbox.htc as in the following snippet where the first line sets the tag name of the component:

<PUBLIC:COMPONENT NAME="cbx" tagName="CHECKBOX">
<PROPERTY NAME="value" GET="getValue" PUT="putValue" />
// Here we place all other properties of the component <METHOD NAME="show" />
// Here we place all other methods of the components <EVENT NAME="onItemChanging" ID="onItemChanging"/>
// Here we place all other events that component will fire to application
<ATTACH EVENT="oncontentready" HANDLER="constructor" />
// Here we place all other events that component handles itself <SCRIPT >
// Here we place all methods, properties getters and setters and event handlers
</SCRIPT>
</PUBLIC:COMPONENT>

Custom Tag Use Case
While the contents of the HTC file matter a lot, the name of the file is irrelevant, although, ultimately, the URL to the HTC file needs to be specified using the IMPORT instruction. It has to be done before the corresponding custom tag is mentioned for the first time (on the page). Here is how the simplest possible page utilizing a custom checkbox might look, assuming the page and the HTC file are located in one folder:

Please notice how custom CHECKBOX has been mapped to a nondefault namespace "myns" in the opening HTML tag. The IMPORT instruction performs a synchronous load of the HTC into the browser's memory and also instructs the browser how to perform name resolution for the appropriate namespace (HTC to namespace association can be many-to-one).

Constructor of the Custom Tag
The best way to initialize HTC, once it's loaded, is to process the "oncontentready" event. Accordingly, we define a handler function, which for sheer clarity is called constructor:

The logic of constructor() is simple: concatenate a regular HTML checkbox and HTML label in the order dependent on the value of property labelonleft (see property definition below):

function constructor() {
// We will add an HTML checkbox and label to the element body
// See Listing 6 for details
}

Defining Custom Tag Properties
To define property labelonleft, we add one more line to the <PUBLIC:COMPONENT> section:

Please note that this property does not contain getter and/or setter methods. Properties onValue and offValue that provide the mapping of the checkbox status into a business value domain also don't need getters and setters:

However, property checked is defined with both getter and setter:

Accordingly, we have definitions for both methods in the <SCRIPT> section. As you can see, setter putChecked(), which is triggered every time checked is modified, sets the value property to one of two variants: onValue or OffValue. Please note that putChecked() will get triggered not only by the script on the checkbox-hosting page, but also by any assignment to checked done inside this very checkbox.htc.

CIO, CTO & Developer Resources

var _value;
function putChecked( newValue ) {
value = (newValue?onValue:offValue);
}
function getChecked(){
return ( _value == onValue);
}

Defining Events for the Custom Tag
Let's look at the definition of onItemChanging and onItemChanged events and how these events are being fired and processed inside the setter for value property (see Listing 6).

Method putValue() has a couple of points of interest. First, it can be called during the parsing on the CHECKBOX tag, as long as the HTML value attribute is specified. That's why we have a separate logic branch for not constructed objects, to differentiate the process of construction from a reaction to a user click. Second, we illustrate here the creation and processing of the custom event onItemChanging, which allows the application to cancel (block) the action. Please note that both clicking as well as programmatic assignment to the value can get cancelled this way.

Event Canceling
To cancel the event, an application should intercept the event and set event.returnValue to false. The schematic snippet of code illustrating how the application would cancel the processing is presented below:=

cbx_1::onItemChanging() {
. . . . .
if (canNotBeAllowed) {
event.returnValue=false;
. . . . .
}

If the event is not cancelled, putValue() sets the internal, plain HTML checkbox's checked property as per the current value: if that is equal to onValue, the internal checkbox will get checked; if it is equal to offValue (there is no third option), unchecked (the full listing is presented in Listing 6).

HTML Internals of the CHECKBOX
The painting of our control is done by the helper functions addLabel() and addCheckBox() and is called from within a constructor(). These functions inject HTML inside the element's innerHTML (element is the analog for this in HTC parlor). The injected HTML, in the simplified form, looks like the following:

<LABEL for=cb_{uniqueID}>Show Details:</LABEL>
<INPUT id=cb_{uniqueID} type=checkbox />

where uniqueID is a unique (within a page) string literal generated by IE, which identifies the instance of the HTC.

Encapsulation ... Again
There is one shortcoming in our CHECKBOX. The way we built it, the HTML injected during the constructor() contributes to the DOM of the page that hosts the HTC. Also global JavaScript variables like_value fall into the global scope of the document they're included in. This is dangerous since we run into the possibility of name clashes: the most obvious case is more than one instance of the same control. In addition, it presents a possibility that our control may accidentally reference other objects with the same names and vice versa.

To put it simply, a special mechanism is required to enable a truly modular approach for object authoring. Fortunately, HTC technology supports an intelligent answer - viewLink.

The easiest way to declare a control as encapsulated is to put one extra declaration between opening and closing PUBLIC:COMPONENT tags:

<PUBLIC:DEFAULTS viewLinkContent/>

Instantly, the control becomes encapsulated; it has its own HTML document tree, atomic to the master document. Every instance of the object has its own set of instantiated values and only public methods and properties can be accessed by the outside code. In other words, the viewLink mechanism fully enables the design and implementation of sophisticated Web applications using a true OO component-based approach.

In particular, we can simplify our code by removing uniqueID suffixes from the definition of internal checkboxes and HTML labels, since we are not afraid of name clashes anymore. Accordingly, we may replace the line:

eval( 'cb_'+uniqueID).checked = ( _value == onValue );

with the

cb.checked = ( _value == onValue );

as well as change addCheckbox() and addLabel() accordingly.

Conclusion
Since the AJAX race has just started, there are no AJAX standards and no commonly accepted RAD tools you can rely on to build your applications. While software vendors have a long way to go to create the robust development platforms, AJAX enthusiasts can prepare by encapsulating reusable blocks of code as business components with a well-defined API.

Navigating in this direction, this article outlined the OO "powers" of the AJAX language - JavaScript. It also illustrated one of the available component-authoring strategies - client-side custom tags technology. While we presented only IE-specific custom tags, we also provide a downloadable example of extensible bindings example for the Mozilla browser. All article-related examples can be downloaded from www.ajaxmaker.com/JDJ/AJAX/partII.html.

« PREVIOUS PAGE 123

Related
Print
Email
Feedback
Add This
Blog This

Intelligent Web Applications with AJAX

More Stories By Victor Rasputnis

More Stories By Anatole Tartakovsky

More Stories By Igor Nys

SYS-CON Media

SYS-CON Events

Navigate

International Sites

Magazines