Now, the code below shows how to derive the class ArithmeticCalculator from the base class Calculator. "Line 1" results in borrowing all properties of the Calculator, while "Line 2" restores the value of the prototype, constructor back to ArithmeticCalculator:

function ArithmeticCalculator() { };
with (ArithmeticCalculator) {
   ArithmeticCalculator .prototype = new Calculator(); //Line 1
   prototype.constructor = ArithmeticCalculator; //Line 2
}

Even if the example above looks like a composition rather than inheritance, the JavaScript engine knows about the prototype chain. In particular, the instanceof operator will work correctly with both the base and derived classes. Assuming you create a new instance of a class ArithmeticCalculator:

var c = new ArithmeticCalculator;

expressions c instanceof Calculator and c instanceof ArithmeticCalculator will both evaluate to true.

Notice, that the constructor of the base class in the example above is called at the point when the ArithmeticCalculator prototype is initialized and not when an instance of the derived class is created. This could have unwanted side effects and you should consider creating a separate function for initialization purposes. As the constructor is not a member function, it can't be called through this reference directly. We will need to create a "Calculator" member function to be able to call super:

function Calculator(ops) { ...};
with (Calculator) {
   prototype.Calculator = Calculator;
}

Now we can write an inherited class that explicitly calls the constructor in the base class:

function ArithmeticCalculator(ops) {
   this.Calculator(ops);
};
with (ArithmeticCalculator) {
   ArithmeticCalculator .prototype = new Calculator;
   prototype.constructor = ArithmeticCalculator;

   prototype.ArithmeticCalculator = ArithmeticCalculator;
}

Polymorphism
JavaScript is a non-typed language where everything is an object. Accordingly, if there are two classes A and B, both defining method foo(), JavaScript will allow polymorphic invocation of foo() across instances of A and B even if there is no hierarchical relation (albeit implementational) whatsoever. From that perspective, JavaScript provides a wider polymorphism then Java. The flexibility, as usual, comes at a price. In this case, it is a price of delegating the type checking job to application code. Specifically, if there is a need to check that a reference indeed points to a desired base class, it can be done with the instanceof operator.

On the other hand, JavaScript doesn't check parameters in the function calls, which prevents from defining polymorphic functions with the same name and different parameters (and let the compiler choose the right signature). Instead, JavaScript provides an argument object - Java 5 style - within a function scope that allows you to implement a different behavior depending on the parameter's type and quantity.

Example
Listing 1 implements a calculator that calculates expressions in a reverse Polish notation. It illustrates the main techniques described in the articles and also shows the usage of the unique JavaScript features, such as accessing object properties as an array element for a dynamic function call.

To make Listing 1 work we also need to provide a piece of code that instantiates the calculator objects and calls the evaluate method:

var e = new ArithmeticCalcuator([2,2,5,"add","mul"]);
alert(e.evaluate());

AJAX Component Authoring
All AJAX component authoring solutions known today can be logically divided into two groups. The first group specifically targets the seamless integration with the HTML-based UI definition. The second group drops HTML as a UI definition language in favor of certain XML. In this article we illustrate one approach from the first group, an analog to JSP tags, albeit in the browser. These browser-specific component authoring extensions are called element behaviors in the IE case or extensible bindings in the case of the latest versions of Firefox, Mozilla, and Netscape 8.

Custom Tag Dialects
Internet Explorer, starting with version 5.5, enables the JavaScript authoring of custom, client-side HTML elements. Unlike JSP tags, these objects are not preprocessed into HTML on the server side. Rather, they're legitimate extensions of a standard HTML object model and everything, including control construction, happens dynamically on the client. Similarly, Gecko-engine based browsers can dynamically decorate any existing HTML element with a reusable functionality.

It's possible, therefore, to build a library of rich UI components with methods, events, and attributes that will have HTML syntax. Such components can be freely mixed with standard HTML. Internally, these components will communicate with application servers, AJAX style. In other words, it's possible (and relatively simple) to build your own AJAX object model.

The IE flavor of this approach is called HTC or HTML components; the Gecko version is called XBL - eXtensible Bindings Language. For the purposes of this article, we'll focus on IE.

Enter the HTML Components - HTC
HTC or HTML components are also called behaviors. In turn they are divided into attached behaviors that decorate any existing HTML element with a set of properties, events, and methods, and element behaviors that look like an extended set of custom HTML tags to the hosting page. Together, element and attached behaviors provide a simple solution for authoring both components and applications. Here we'll illustrate the most comprehensive case, element behaviors.

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.

<checkbox id="cbx_1" value="N" labelonleft="true"
label="Show Details:" onValue="Y" offValue="N"/>

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