Davin's approach for MDI/GUI/GRID

The Phoenix Skeleton

Carl asked me to develop for him an application framework that he could use to build a number of different applications. He called this skeletal framework "Phoenix". So I designed a very lightweight workspace that could be used to provide a flexible GUI front-end for computational code.

The "View" Concept

As a general rule, any collection of data may be interpreted in a number of different ways - in effect looking at it from different points of view. We shall call each of these ways a view. Each view shows the user some or all of the data, organized or summarized in a way that is useful to the user. Phoenix is structured to present multiple simultaneous views of a single set of data.

Design Plan

Of course, not every application works in the same way, so we've made the following assumptions and requirements on how Phoenix-based applications should operate:

• It handles only a single set of related data at a time. User I/O commands are typically provided to change the set of data in use.
• It works most efficiently when the entire set of data is small enough to fit in the workspace.
• It will use the idea of (multiple) views to present data to the user. Any particular item or summary of data may be present in more than one view.
• Views may be used to enter or edit data as well as present it as output.
• It will provide an MDI-style application to contain those views so that several can be seen (and managed) at once.
• Each view is displayed to the user as a single Form object contained within the MDI.
• The user (not the developer) is in control of which views are being presented to them at any given time.
• The developer is responsible for designing each form to be used for presentation. This might, for instance, be composed of a single, simple grid object. But it could also be an arbitrarily complex form if desired.
• The developer specifies what data (usually stored in temporary globals) is to be placed on these view forms. In a simple grid case, this might just be the name of a matrix to be used to fill the grid.
• The developer controls when the views are visually updated by executing a simple "Refresh" command.
• The definition of each view is stored in an APL file. These "view files" are completely independent of one another.
• The views available to the user are determined simply by the presence or absence of such files - the user interface varies to match them at execution time.
• The application can often be updated in the field by adding or replacing individual view files, without having to redistribute the entire application or workspace.
• Views may be dynamically enabled or disabled (in the GUI) as the data changes. For instance, certain views can be switched off (greyed out) when they are not applicable to the current data.
• View-specific menu items and command buttons may be defined and used. (They may do different things depending on which view is active at the time they are used.)
• Lots of flexibility is made available to the developer for any special needs that may arise.
• The application's computational code is kept separate from the presentation and is executed on demand. Communication between computation and presentation is expected to be via global variables (or a similar mechanism).
• Other forms of I/O (such as printed reports) may also be used in the application. They should be provided by facilities separate from Phoenix itself.

Conclusion

The above design sounds like it may have only limited use, but Phoenix can actually be used for a fairly wide variety of applications, particularly those involving lots of calculations or the presentation of complex data. The implementation is small, fast, and very customizable. The code for Phoenix is available on the conference disk. Keep in mind that it is a work in progress, so the code isn't very "clean and neat" in some places, and new features are still being added.