Using communication channels in applets, Part 3

Develop Visual Basic-style techniques to applet design -- convert temperatures, too!

By Chuck Mcmanis, JavaWorld.com, 06/05/96

The environment that applets find themselves running in is already rich with expressive power for laying out documents. Why not do that with applet applications? You use tables to lay out forms, don't you?

To take advantage of this unique position that applets find themselves in, I set out to develop some building-block applets that could be combined into unique applications. To some extent this idea is "stolen" from Visual Basic, but in truth it bears nothing in common with that system, only a common way of explaining some of its features so that if you are familiar with Visual Basic then you can understand what these applets are trying to do. However, I'll start by looking at the traditional interface before jumping into this new one.

In nearly all modern window systems there is a notion of a containing window or frame and some subsidiary controls, which are sometimes called widgets. The basic application that controls such an application is written, at a gross level, to be something like:

begin 
    initialize window system, create base window.
    Create some controls, add them to the window.
    Open up the window.
    while ( not done ) do
    Get an event from the window system.
    switch on EVENT:
        case MENU
        do menus.
        case SELECT
        do select.
        case KEYBOARD
        do keyboard.
        case I/O
        do I/O.
        case EXIT
        leave.
    end while.
end application.

One of the disadvantages of writing a window-based tool in this way is that it doesn't necessarily take advantage of threads easily. Another disadvantage is that if the subroutines for handling events are "slow" getting back to the event loop, response can be problematic. Finally, it can be very difficult to generate "synthetic" events -- events that are generated as a computed result of a user's interaction, not necessarily direct user interaction.

So what is different about the applet environment? First, the window in which the applet operates already exists. The browser has created it for you and is already dealing with input from it. Secondly, applets today mostly live in WWW browsers, which already know how to lay out pages based on formatting codes that the user has input.

How might one take advantage of this? I did it by designing a collection of applets that were each a single "control" running in its own thread, and communicating with other controls using inter-Thread data channels. (So you see, part 1 and part 2 of this series were not a waste of time.) At the highest level these applets appear as individual items on the page, so you can lay them out with HTML tags like you would lay out images or forms. However, unlike forms, applets can interoperate without constraint. A typical form might appear in HTML as follows: