The Zim Application Model

We describe the Zim application model by first describing its characteristics from a user’s point of view. Then we look at the architectural and implementation characteristics of the model. The objective is not to come up with a formal definition of the model. Instead, we need a broad understanding of the model so that we can then proceed to how this model is used by DC in generating applications and how it is used within the Application Framework.

User Perspective

With the application model, Zim applications are organized into windows. The “main” application window is the first window that appears and it normally stays open for the duration of the application. From the main application window, the user can launch or open other windows. From those windows, more windows can be opened, and so on.

In some applications, when a window is opened, the user is forced to interact only with that window. These windows are called modal windows. In other applications, the user can interact with any open window. These windows are called non-modal. In general, applications contain a mixture of modal and non-modal windows.

When non-modal windows are employed, the user is in much greater control of the application. He/she decides the window with which to interact at any time. By contrast, where only modal windows are used, the application decides where the user can interact. For this reason, applications with non-modal windows are often said to have event driven interfaces. When modal windows are used, the application interface is application driven.

For readers already experienced in writing Zim programs, Appendix B provides a number of examples that compare and contrast older programming styles with newer event driven styles.

Implementation and Architecture Perspective

Event Driven

To support applications with the above characteristics, the Zim application model organizes applications as follows:

• every application contains a single program that contains an event loop. This program contains a loop that gets user interface events (for example, click events or accelerator keys by means of FORM INPUT) and then directs the event to the correct program for processing.

• each window has an associated program that manages the user interface. The program is designed to receive (by means of input parameters) the event to which it must react. It processes the event and then exits.

This architecture is diagrammed below and enables “event driven” interfaces. User interface events are received in a single location (the program that contains the event loop) and are dispatched to the appropriate program that manages the window for which the event is directed. Where a user interface is to be modal, the window would be declared as modal. This ensures that the user is prevented from interacting with any other window. In designing the associated window management program, there are two choices. The program could contain its own event loop or it could be organized like any other window management program.

Separation of User Interface and Database Processing

Many windows are designed to view and/or update data in the database. In this case, the program associated with the window should be designed to deal primarily with user interface issues. A second program should be created that handles the actual database interactions. This second program could also include specific validation and referential integrity processing.

This division between user interface processing and database processing is very important. It makes it much easier to make changes to the user interface while retaining the same database processing code, which, after all, should be independent of the user interface. Furthermore, the database program can be tested independently from the user interface to ensure that it meets all data integrity and correctness rules.

The overall architecture of the application model is illustrated below.

Note: The Example Application distributed with Zim is a good example of an application that is built using this model. In fact, the Example Application was built using the Application Design features of the Development Center.