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.
Of course, not every application works in the same way, so we've made the
following assumptions and requirements on how Phoenix-based applications
- 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
- Views may be used to enter or edit data as well as present it as
- 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
- 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
- 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
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.