The Code
The AjaxWord client consists of JavaScript and HMTL code. The application's user interface is defined in HTML. Client-side logic written in JavaScript defines the behavior of the user interface by leveraging a generic JavaScript/DHTML toolkit that's built from scratch. From a Model-View-Controller perspective, the HTML files are "Views" and the JavaScript code acts as "Controllers."

The JavaScript/DHTML toolkit defines all the UI widgets. By separating UI widgets from the application, it's easier to develop and maintain the application code. Because of the level of richness required by AjaxWord and the limited availability of AJAX toolkits in the late 1990s, this entire toolkit was written from scratch. It would have been easier to build AjaxWord today by leveraging some of the available toolkits that have emerged in the last 12 months.

A Generic DHTML/JavaScript Toolkit
The AjaxWord DHTML/JavaScript toolkit is a generic toolkit that contains a list of rich user interface components, event management, and code for doing asynchronous communications.

In Figure 10, the left items are available with Web browsers. All other items aren't available in browsers and have to be built from scratch. In addition to UI elements, the toolkit provides a systematic way of managing UI events and doing asynchronous communications. When the application was written, the popular XmlHttpRequest object wasn't available in browsers, so AjaxWord actually uses hidden frames to asynchronously communicate.

Instead of elaborating on how each component is built, we will use the "window" object as an example. The window object that we are referring to is a draggable, resizable window that resides inside a standard browser window, giving the look-and-feel of a multiple document interface. It is a basic component for desktop application user interfaces, but isn't available for Web applications.

Creating a "Window" Widget
Figure 11 shows how an AjaxWord UI Toolkit window is running inside a browser alongside some HTML text. We'll explain how to define its view and its behavior below.

Defining the View
The view is defined using HTML. To mimic a window look, the view defines 14 different areas of a "window" user interface: the four corners, the four edges, the window content, the title bar, and the four window control areas (close, maximize, minimize, and the window icon). Figure 12 shows how a window user interface is split into 14 different regions.

Each window area is defined by a "DIV" tag. For the four corners and four edges, each DIV tag contains an image. Each of the four window controls also contain an image. When necessary, these images can be changed according to style requirements. Some of DIV tags have event handlers defined too so that the window can respond to events. The view definition code is shown in Listing 1.

Defining the Controller
The controller logic of a window widget is defined using JavaScript. The JavaScript file "NWindow.js" is one of the controllers that define the basic behavior of a window widget.

Window Initialization
When a window is created, "NWindow.js" initializes it by connecting the JavaScript object with the "view" object (HTML code), hooking up event handlers and initializing object properties. See Listing 2 for the initialization code.

Window Event Handling
The JavaScript file handles various window-related events such as resizing the window in response to mouse-drag events on the four edges, maximizing the window or closing the window in response to mouse-click events, or moving the window in response to mouse-drag events on the title bar. On the other side, the JavaScript file also fires window events to the toolkit's event management system so that if a listener is registered for a certain window event, the listener can be called.

Window Widget API
The JavaScript file also provides an API for developers to program this window object, such as setting the window title or resizing the window programmatically. The code in Listing 3 lets developers set the title, status, and icon of a window object

AjaxWord Client Application Logic
AjaxWord does a significant amount of processing on the client side for application performance reasons. With a lot of code on the client side, applications can deliver better performance. However, such applications must be designed and coded carefully to avoid code maintenance problems.

The abstraction of UI widgets into a generic AJAX toolkit certainly helps code maintenance. AjaxWord also uses an object-oriented, event-driven approach to develop the application's client-side logic to manage and maintain the client-side code.

All client-side logic resides in two JavaScript files: nwWord.js and nwWordMenuListener.js. The first JavaScript file defines the application-wide logic while the second one responds to menu and toolbar events.

Loading the Application
For applications that have a significant amount of code on the client side, developers have to consider how the application is being loaded. Otherwise users will think the application is slow and abandon it.

AjaxWord requires a significant amount of initial download (several hundred kilobytes, dozens of HTML and JavaScript files, and many image files). This download process can take anywhere from a few seconds on a fast connection to 40 seconds on a slow dialup connection. To engage the user and improve perceived performance, AjaxWord uses a progress bar to indicate the loading progress so that the user knows the status and gets constant visual feedback, as shown in Figure 13

AjaxWord uses the code snippet below to update the progress bar and the status message. This code snippet follows each JavaScript file declaration statement so the "loadProgress1()" method will be executed every time a new file finishes loading:

<SCRIPT TYPE="text/JavaScript">loadProgress1();</script>

This way the user sees the progress being made as the application loads. Listing 4 is the loading page for AjaxWord.