In this article we describe how combining WML, ColdFusion, and the Fusebox methodology enables wireless data updates of the data- base of a working e-commerce Web site. To provide some context, we begin with a discussion of what this Web site is and what it does.

NetLook, Inc., is a client of our company, Applied Digital Solutions' Oracle Practice. Its Web site (www.netlook.com) is designed to advertise used cars and help people find jobs (see Figures 1 and 2). NetLook lives in a cluster environment of two NT servers, each running IIS, and ColdFusion Server. These servers also hold the file system that contains auto, job, and customer files (e.g., auto pictures and customer logos).

Heavily involved with multimedia, NetLook presents information via a dedicated cable television station and weekly hard copy publications, as well as over the Internet.

One of NetLook's main features is that the job- and car-related data for these three communication channels comes from a single Oracle database. For the Internet, ColdFusion Server reads the information from the database and then displays it on the NetLook Web site.

A two-step process generates two hard- copy publications, one devoted to automobile sales, the other to job ads. First, a ColdFusion program extracts all the data (car pictures, dealer logos, and car and dealer information) from the file system and the database. Quark then uses this information to automatically generate the magazines.

Producing the TV-based information also involves a two-step process. As in the case with the hard copy, a ColdFusion program first extracts the information from the file system and database, then a NetLook AV specialist synthesizes this information for production into a televised broadcast.

The Role of ColdFusion
Visitors to the NetLook Web site access the database through a front-end written in ColdFusion. To modify the data, NetLook employees also access the database through a ColdFusion-based user interface. They enter data and photographs into this interface, then upload them. In the case of used cars, NetLook provides a marketplace for dealers as well as for individuals. An auto dealership can have its own Web page on the NetLook Web site. To accomplish this, NetLook creates frame-based HTML code for each dealer.

A dealer can select from many types of information (e.g., financing, contacts, inventory) and then display that information on his or her own site. The frame-based architecture enables the dealers to upload their own HTML pages, have those pages appear in sections of the screen, and maintain the navigation across them.

Dealers, of course, often have to modify their own NetLook-based data to keep it current, and ColdFusion is also the basis for the user interface through which they do this.

NetLook and the World of Wireless
With the increasing emphasis on wireless technology and the emergence of WAP and WML, it's possible to add the wireless data update dimension to the NetLook database. Specifically, the combination of ColdFusion with WML forms the basis for an exciting new capability - a capability that enables a NetLook employee to use a wireless phone to accomplish data update.

The modified data is then immediately available over the Internet, on NetLook's next cable TV show, and for the next issues of its hard-copy publications.

In the rest of this article we describe the nature and structure of the programming that makes the data update possible via wireless technology. We also discuss Fusebox, the methodology that's the basis for the code. The programming centers around a wireless phone emulator, available from www.phone.com (see Figure 3). The code is easily transposable to cell phones, with minor modifications to adapt to specific phones.

Working with WML: Concerns and Constraints
Dubbed a deck, a WML program consists of cards. Each card corresponds roughly to one screen, although device-centric display constraints sometimes entail additional screens for the displayed information.

Code that might encompass multiple HTML files can often appear in a single WML file that consists of many cards. Nevertheless, download constraints typically limit the size of a WML file. It's also the case that all cards within a deck are downloaded at the same time. This sets up another type of constraint: if one card initiates server-side processing based on user input to a display generated by a different card, these two cards must reside in separate decks.

How is WML processed? Wireless Internet providers typically offer a service that translates WML requests into HTTP requests. Each HTTP request then goes to a ColdFusion/IIS server, which processes the request, then a ColdFusion program generates a WML file and sends it back to the end user's wireless device. Both the device-centric and download constraints we mentioned before pertain to this generated WML file, not to the ColdFusion program that created it.

Fusebox: Structured Programming for a Stateless World
A hand-in-glove fit with WML, the Fusebox methodology forms the framework for the wireless NetLook programming. Similar to structured programming of several decades ago (as typified by the Modula-2 programming language, for example), this methodology sets up a main program whose explicitly delineated components interact with outside programs (i.e., modules). As with structured programming, a main objective of Fusebox is to enable multiprogrammer teams to work seamlessly on large projects.

Fusebox is different from earlier structured programming techniques - it turns them inside out. In classical structured programming the main program is a sequence of calls to functions and subroutines that carry out the bulk of the processing. In contrast, the Fusebox methodology's main program is a switch statement (denoted by a tag). Each case in the switch statement (denoted by ) carries out a processing module and serves as a target for external calls to the main program.

Parameters in an external call determine the case of the switch statement that activates and completes its tasks. Statelessness necessitates this. Because the main program doesn't track or remember its own state, the switch statement provides an easy mechanism for entry into the appropriate point of the main program and for sequencing the processes it carries out.

In ColdFusion, this main program is usually called index.cfm and should handle every request sent to the server. A parameter, usually named fuseaction, plays a key role in helping the server figure out what the user needs. Typically, the fuseaction contains values such as "login", "logout", or "save_info". The list of values for this parameter should encompass all the different actions the user is allowed to perform. Additional parameters may be needed to complete the request. When using the fusebox methodology to write an application, the programmer must make sure that the fuseaction values handle all the use cases. (For more information on this methodology, visit www.fusebox.org.)

Conventions
Naming conventions are extremely important in our framework. They make it easy to follow how filenames for cards are constructed, how one card's code references another card, and how a card references decks. Knowing our conventions will also help you follow Listing 1. (Listings for this article can be found on the CFDJ Web site, www.sys-con.com/coldfusion/sourcec.cfm.)

Each file whose name begins with dsp_ contains the WML for one card. If the card requires SQL to load the relevant information to the page, the SQL must be included.

To clarify the discussion, imagine two cards. Each card in a deck must have a card ID, so let's say the IDs for these cards are CardID1 and CardID2.

Our convention uses the card ID in the filename by prefixing it with dsp_ and adding a .cfm extension. So the name of the first card's file is dsp_CardID1.cfm and the name of the second one's file is dsp_CardID2.cfm. Listing 2 shows one of our dsp_ files, dsp_message.

Suppose CardID1's code has to reference CardID2. In a do statement within CardID1 a variable suffixed with _href gets that done. By our convention, the name of that variable will be CardID1_href, and the value it holds will be #CardID2.

An _href-suffixed variable can also handle a reference to a deck. If CardID1's code has to reference a deck, the variable Card-ID1_href appears in a do statement and its value is index.cfm?fuseaction = deckaction, where deckaction refers to the fuseaction of the referenced deck (i.e., to the use case that the deck's fuseaction fulfills).

Two more conventions and then we're done:

1. Act_ file: Performs an action on the server side, such as updating the database or setting a variable. These files are strictly ColdFusion programs.
2. App_ file: Contains code used by every program in an application. This type of module might contain global variables and security checks.

The fuseaction value refers to one of the cfcase statements, which then executes. Each cfcase statement holds a series of cfset and cfinclude statements. The cfset statements define the value of the variables used within the templates that are included in the cfinclude commands.

Each cfcase may refer to zero, one, or more dsp_ files. If no dsp_ files are included, the request is processed in the background. An example is . This particular cfcase retrieves information from the database about a particular car and initializes WML variables.

A cfcase can refer to a single dsp_ file for two reasons. First, only one dsp_ file may be included if the card displays information that depends on user input to a previous card. Second, the size of the card's content may create a download constraint, leaving no memory available to download additional cards.

In our index.cfm file (see Listing 1), provides an example of both possibilities. This code displays all the models for the particular make that the user entered via a previous card. Because the model depends on the make, these two cards must reside in separate cfcase statements. Also, the list of models might be very long, leaving no room to download other cards.

Two or more cards might be in the same deck if the cards' contents leave enough space to download more than one. Typically, however, it's best to keep them in separate dsp_ files to maintain flexibility. If it becomes necessary to shuffle cards, it's easier to do it if they're in separate files.

Wireless NetLook: How It Works
Listing 1 shows the main program, index.cfm. One overall point about the code further reinforces Fusebox's value: index.cfm contains business logic and is written in ColdFusion. The WML resides in other files (e.g., in ColdFusion modules), is interspersed with ColdFusion, and performs actions such as information display and server-side processing. Thus Fusebox separates business logic from the rest of the code. If the logic changes, major surgery isn't necessary to modify the program.

The first three cases in the switch statement deal with login and session monitoring. The fourth case confirms login and displays a menu for the end user.

The next case - the one that begins with - responds to the user's menu selections. The case after that () allows the user to select the auto dealership in which he or she will update auto information.

These two cases work together in a special way. The menu items work from the premise that the user has selected a dealer. The normal sequence, then, is for the user to select a dealership before the menu displays. Sometimes, during the course of a session, the user has to update car information from a different dealer so the "sel_customer" case must come into play again. For this reason the "menu" case and the "sel_customer" case generate the same cards. The net effect (pardon the pun) is to eliminate repeated downloads of the menu. To understand menu creation and operation in greater detail, see the sidebar "Custom Tags for Menus and Menu Items."

In either case, the user enters a VIN (vehicle identification number) for a particular automobile. If that VIN is in the database, the next case () populates onscreen fields with appropriate values for the car that corresponds to the VIN. If that VIN isn't in the database, obviously the user must supply values for these fields.

How does the user modify or supply those values? The next seven cases, in which "value" ranges from "autodeck1" through "autodeck7", deal with the user's entries that update the fields. Each case displays information, gets a piece of data update-related input from the user, and uploads to the WAP server. After each upload, the WAP server generates an HTTP request and sends it to the ColdFusion/IIS Server, where a ColdFusion program generates WML that goes back to the wireless device. The code sent back to the wireless device specifies that the next case should activate, get user input, repeat the process, and further augment the parameter list. As the program progresses, each case of the switch statement adds a parameter to a list of parameters.

When the user has finished updating, the last of these case statements sends the fully built list of parameters to the ColdFusion server. Then the next case () runs SQL code that uses that list to update the database.

Wrapping Up
The wireless work we described is a significant step forward for NetLook and our company. It paves the way for NetLook to reach its customers and users in an important new dimension and sets up our work for a variety of clients in the wireless future. Experiments that use this code in conjunction with a NexTel phone have been successful.

We feel that Fusebox represents a significant portion of this effort. This methodology has enabled the creation of an architecture that positions the business logic of the system in a central block of code and puts the nuts and bolts of the processing in supplementary modules.

In addition to the obvious facilitation of development and maintenance, this type of architecture holds another important advantage: when bandwidth increases (as it always does!), it'll be possible to take advantage of the increased capability by adding more cards to a deck. This will facilitate downloading and display without tearing apart the fundamental structure of the program.