GUI Widgets

WT Toolkit provides a rich GUI widgets library that is commonly needed in developing rich Internet applications. GUI widgets in WT Toolkit are all object oriented so that sophisticated widgets can be built by aggregating and inheriting from simplier widgets.

Some examples of interesting widgets found in WT Toolkit's GUI widgets library include: sortable (and editable!) tables, translucent windows, trees and tabbed pages.

Feature Demo

Vector Graphics

The vector graphical widgets system in WT Toolkit allows drawing vector graphics in Internet Explorer 6+ and Gecko-based browsers (e.g. Firefox) without requiring any third party plug-in. Vector graphics are drawn by adding VML nodes under the document tree in Internet Explorer, and by adding inline SVG nodes to the document tree in web browsers using the Gecko engine.

Apart from being able to draw simple shapes like ellipses, polygons and lines, the vector graphics system in WT Toolkit is also able to construct more sophisticated and tangible widgets. For example, it can construct 3D objects and many different kinds of charts, such as 3D bar charts, 3D pie charts, broken line charts, curve line charts, scatter charts, radar charts, etc.

Feature Demo

AJAX Forms and RPC

It is well known that AJAX techniques are useful in making web applications more responsive, and also in reducing the workload of web servers. Building AJAX web applications upon the vanilla XMLHttpRequest object can be troublesome, however. This is partly because it does not provide data serialization service for sending data objects to the web server, and partly because it needs to be programmed differently for different browsers.

Why AJAX RPC? WT Toolkit provides an AJAX RPC mechanism which works the same no matter viewed under IE-based or Gecko-based browsers. It also includes a data serialization/deserialization service based on JSON. Since AJAX is asynchronous in nature, event handling logic is inevitable in programming AJAX RPCs. AJAX RPCs can be programmed through the signal-slot event system in WT Toolkit, which is much safer than using the onreadystatechange event hook of XMLHttpRequest directly since our implementation is immune to memory leaks under Internet Explorer.

AJAX Forms. Integrating AJAX RPC with traditional HTML form input widgets results in the AJAX forms system in WT Toolkit. Unlike some other AJAX forms systems, the form system in WT Toolkit is completely object oriented and any changes in form input values can be tracked by other parts of your web application via signal-slot events. This makes our form system much more flexible and extensible. For example, complicated input widgets like spreadsheet-like editable tables can be made from aggregating multiple textboxes, as shown on the image above.

Feature Demo

Signal-Slot Event System

The event system implemented in WT Toolkit is modeled after the signal-slot system found in the desktop GUI toolkit Qt. We chose to implement a signal-slot event system in WT Toolkit for the following reasons:

It is intuitive. Imagine you just heard a telephone ringing. Naturally, you would pick up the telephone and answer it. The ringing sound from the telephone can be modeled as a signal, and your reaction to the ringing sound can be modeled as a slot. A programmer using WT Toolkit can easily picture event handling in web applications as things he would do in everyday life - it is easy to picture an object emitting a signal as a ringing telephone for example. In contrast, it is difficult to imagine an intuitive picture when a callback mechanism is used to handle events instead.

It loosens coupling between objects. In the telephone example above, the telephone does not care whether there's anyone listening to its rings or not, nor do the user has to be prepared for the phone to ring when he walks near the telephone. When translated to programming terms, the programmer writing the telephone and baby tux can care less about the objects' environment, and care more about the functionality of the objects. Programming events in signals and slots reduces a program's complexity in the developer's eyes.

It feels familiar. If you've been an application developer for some time, programming events with a signal-slot system feels like talking to an old friend. A signal slot event system is one way of implementing the observer design pattern, which is a common technique for event handling under many different platforms and development environments. Qt is an obvious example. The event handling mechanism used in AWT/Swing in Java is also a straightforward implementation of the observer pattern. How about event handling in wxWidgets? Same technique, different implementation. The observer pattern is not only found in GUI programming, you can easily find it in embedded system development even. For example, much of the message sending mechanisms in nesC is built upon the observer pattern.

Feature Demo

Resistant to Memory Leaks


WT Toolkit uses an object model based on weak references and proxy pattern to isolate leak-prone and memory expensive objects (such as DOM nodes). In WT Toolkit, day-to-day operations to objects are performed from light-weight proxy objects based on the wtObject base class instead of operating directly on the memory expensive objects themselves. This makes web applications written in WT Toolkit resistant to memory leaks resulted from circular referencing and lapsed listeners, even though you are writing closures everywhere in over your code, for the following reasons:


No circular strong references. It is well known that circular references involving DOM nodes in JavaScript can induce memory leaks that persist after page refreshes in Internet Explorer. (reference: this article, and this MSDN technical report) The weakly referencing object model in WT Toolkit guarantees that strong circular references are impossible by ensuring that DOM node references are referred by weak references instead of the strong reference. As a result, WT Toolkit does not need to use a window.onunload hook to clean up circular references to avoid memory leaks - because there were no circular references to begin with.

No lapsed listeners. "Lapsed listener is when an object is added to a collection but never removed. The most common example of this is an event listener, where the object is added to a listener list, but never removed once it is no longer needed."

-- Ethan Henry and Ed Lycklama, "How Do You Plug Java Memory Leaks?"

Many of the current AJAX/JavaScript toolkits available now (e.g. Dojo Toolkit, Prototype) are susceptible to memory leaks via lapsed listeners. For example, in Prototype v1.5.1, if you create a lot of short-lived DOM objects and connect them to event handlers with Event.observe(), the DOM objects in question will never be freed before a page refresh even if you have removed the DOM objects from the document tree and called Event.stopObserving(). The reason is that the DOM objects are not properly cleared from Prototype toolkit's event handling system even though you called Event.stopObserving().

In WT Toolkit, however, lapsed listener is no longer a significant concern for application programmers. WT Toolkit's event system is able to clean up event listeners correctly and automatically when the user calls wtObject::disconnect() or when the event listener's usefulness has lapsed (e.g. a DOM node listening for event is removed from the document tree). In most cases, the application developer does not have to care about lapsed listeners at all - he can just connect the signals and slots and forget about them.

Implicit object cleanup by dependencies. Often times, you may have objects whose usefulness depends on the existence of another object. For example, the usefulness of an AJAX request object may depend on whether a visible window widget still exists or not. In other toolkits, the programmer might have to remove that AJAX request object from being referred to from other objects and from the toolkit's event system whenever the window is removed. This can get very tedious when object dependency relations are getting complicated. In WT Toolkit, however, the programmer can declare an object's dependency on another object, such that when the dependee object is removed, the dependent object would be automatically cleaned up also.