T ECHNIQUE : GENERATING S WING DIALOG BOXES

Swing is a cross-platform UI class library built entirely in Java. The Swing class library is intended for desktop application development and supports all of the modern inter- action models, such as documents, modal and modeless dialog boxes, menus, and tool- bars. Not only is Swing portable between all of the common operating systems, it also emulates the look and feel of those platforms. An application written in Swing looks as if it were written for its operating system directly. In this section, we'll discuss a generator that builds a Swing-based UI.

5.5.1 Generator requirements

Swing implements dialog boxes as code; there is no resource file from which the Swing library reads a dialog definition and creates controls. Building a dialog box involves building a set of control objects, containers, and callbacks in Java code. As with most interface toolkits, the business rules that drive the interface get lost in all of the con- struction and maintenance minutiae. An ideal generator architecture allows you to keep the business logic of the interface separate from its Swing implementation.

The details in a Swing dialog box can be divided into two groups. The first group includes the relevant details for the business side:

• A data source for getting and setting the data • Fields

• Basic types of the fields (e.g., String, Integer) • The layout of the fields

• Which fields are editable

• Which validations should be applied to each field • Which cross-field validations are required

The next set of items provide the implementation details: • Swing objects that represent each field

• The dialog class

• The constructor that builds the class and lays out the fields • Event responders that listen for button presses

• Code that implements the field and cross-field validations

In a hand-coded dialog box, the items in both lists are mixed together in the imple- mentation. The generator handles the implementation details and thus allows you to concentrate on the business details.

We have to be realistic, however. A generator will not be able to handle all of the edge cases in the user interface. Login pages are an example of edge case pages that are

often custom built. This is because the logic for supporting the page, validating the login information and privileges, and initiating the session is singular to the login page alone. So generating this one-off page is inefficient. For that reason, we need to be able to add custom code to the process so that we can override or extend the output of the generator to handle edge cases.

Note that with the exception of the Java types in the business details and any cus- tom edge case code, the business details are platform neutral. This lets you maintain the portability of the business logic for the interface. If you decide to change plat- forms, you can move the dialog boxes by mapping the Java types and porting the edge case code. Even if the generated output isn’t a complete solution, you will still be fur- ther along than if you had tried to port the Swing code directly.

5.5.2 Architectural recommendation

In this example, the business requirements tell you that you need to take the business details and custom code as input and create the Java Swing code to manage the dialog boxes. The block architecture for a Swing dialog generator, based on the tier generator model, is shown in figure 5.10.

The generator reads the business details from an XML definition file. When custom code is required, the definition files reference an external file that contains the required Java code. The generator takes both of these inputs and merges them, using a reservoir of templates, into Java implementation files.

The templates are fairly simple. First you have a framework template that builds the basics of the dialog class. Then, there are control templates for building each of the types of controls for each of the fields specified and for doing the validation of those controls when processing the OK click.

Generator Definition Files

Swing Java

Dialog

Class Table Dropdown Checkbox

Custom Code Files

Validations _HandlersEvent

Business Logic

DB Figure 5.10 A generator that builds Swing classes

TECHNIQUE: GENERATING MFC DIALOGBOXES 121

5.5.3 Processing flow

The processing flow of the generator is as follows:

● Reads and validates the definition XML files and stores the information in local

structures.

● Checks for any custom code references. Reads in the code files and stores them in

the local structures.

● Iterates the following steps over every dialog box defined in the XML file: ❍ Initializes caches of code for the variable declarations and the methods. ❍ Iterates over each field and performs the following steps:

◗ Builds and caches the field definitions.

◗ Builds the event handlers and adds to the methods cache. ◗ Adds any custom per-field to the methods cache.

● Handles any per-dialog custom code by adding the code to the methods cache. ● Uses the Java Dialog Class template to create the implementation for the class.

This template should contain the class, the constructor, and the standard event handlers. The variables and methods text from the field processing steps should be merged into the output.

● Stores the output of this template in the .java file with the correct name.

5.6

TECHNIQUE: GENERATING MFC