Original Vision for the P.V.Player
The Plain Vanilla Player is a multi-dimensional platform from which to manage
all aspects of user I/O including data entry, report generation, database management and
context sensitive help integrated with APL functionality. It can be
deployed on a stand-alone basis under Windows or on the APL2000 web server.
It includes specifications for generating forms on four platforms (APL2000 grid, NewLeaf, Excel, HTML)
and for maintaining prearranged "views" of a complex database.
Each "view" can be rendered in any of the four platforms.
It is presently being used to create software products built upon two complex economic models.
It is also being used for less complex purposes, but the overall scope is dictated by the
needs of the two economic models.
- Scope and Principles of Design
- I/O Platforms
Consideration of our four major I/O platforms sets the stage for understanding
the scope of our work (APL2000 grid control, NewLeaf, Excel, HTML).
The sorts of tasks for which each of these platforms is used are the sorts of tasks we must handle well.
Furthermore, our data structures and specifications must translate easily to each of
these platforms using "drivers" which we write and maintain.
- APL2000 grid control
The high degree of interactivity and performance speed using the APL2000 grid control is very important.
The capacity of NewLeaf to create superb documents is simply splendid.
We expect that the APL grid control with NewLeaf preview and printing will be the "heart and soul"
of the Plain Vanilla Player. We look forward to adding the capabilities of RainPro.
The interface between APL and Excel has been highly developed by APL2000
and we expect our use of the APL grid control to be replicated in Excel before our annual users meeting in Naples.
Use with Excel will work satisfactorily and
will be a big advantage to getting "in the door" of sales prospects, but it is not likely to match
the real interactive performance of the APL2000 grid control.
- The APL server
Later the "heart and soul" may be in
use on an APL server in a .net strategy, but first revenues will be from use in Windows.
- Data Structures
Data is made easy to handle with the broad use of "property value pairs" (PVP's) or "property value matrices" (PVM's).
The primary data structure is called an "M1M".
It is best understood as narrative text and/or a related table and the properties needed to
use them in the four I/O platforms.
If more than one "M1M" is to be used for a form (or document or view or report),
then many M1Ms can be catenated into a vector with another structure as an optional first element to
provide an overall title, table of contents, and template instructions.
These data structures have a specific list of properties (listed below).
- Styles & Galleries
A great deal of simplification is achieved through the use of "galleries" inspired by NewLeaf.
For example, NewLeaf provides for a very high level of specificity in how
various report elements will be handled. We allow the user to specify just 3 items
and a gallery is generated providing for how a broad array of items will be handled.
The three items to be specified by the user are base font size, paper size and orientation.
Similar use of simplified specifications extended through galleries of related specifications
are used throughout our Plain Vanilla Player. Of course, the user working directly with NewLeaf and RainPro
has far more power for customizing reports, but our approach has the advantages of ease and speed.
The name "Plain Vanilla" is our way of acknowledging this simplification for ease and speed.
- Views, Forms & Reports
We view these three terms as interchangeable because each is generated from the same structure of source specifications.
- Standard Views
An application is likely to have a variety of views, forms and reports that are applicable to all uses of the application.
They include management reports as well as views needed to show source data and all that is needed for auditing.
- User Defined Views
It is certain that the user will want his or her own highly specific forms, views and reports.
It is our intent that the "Player" idea in the name of this platform
will accurately convey the ease with which users can create their own views.
Our simplified conventions, galleries and utility structures are expected to make the "Player" possible.
User created views can be rendered in any of our platforms.
- UDSC (User Defined Supplementary Code)
APL executables are important to the system and in this term we'll document the ways in which they can be used.
In principle, any parameter can be expressed as executable APL code, though we'll implement this
possibility as it becomes needed.
- Compiling the MDI form
Our HTML menu structure looks a great deal like our Windows MDI form.
Both can be generated from the same source specifications and easily updated
when the source specifications are changed.
- How It All Hangs Together
- The Phoenix Skeleton
The MDI and all views, forms and reports are organized by a workspace we call Phoenix
that was designed by Davin Church. It is 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
- 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
- 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.
- Since views are defined by files rather than by code, custom views may
be constructed and used as if they were native views, without requiring any
- 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 itself.
Conclusion on the Phoenix Skeleton
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.
Data Structures and their Properties
Our data structure has the purpose of providing a list of properties
robust enough to produce a wide variety of complex documents.
It also has a second and possibly more important purpose and that
is to provide the bridge between complex algorithmic processing on a server
and potentially highly customized and tedious report generation ("tinkering") at the client end.
It is possible that the Plain Vanilla Player will work on the client machine
while complex processing occurs on a server.
That will make it possible to charge a substantial fee for the work that only we (our black box)
can do while charging only a one time fee (with upgrades) for the time consuming
customization that our customers will want to do.
- Specific Data Structures
This describes our data structure and definitions important to the data structure.
- PVP - "Property Value Pair" (vector of pairs or two column matrix), but sometimes it means Plain Vanilla Player,
so we avoid use of the acronym "PVP".
- PVM - Property Value Pairs arranged as a two column matrix (the kind of PVP we use).
- M1M - a PVM with a specific set of properties.
- M3M - a vector of M1M's, capable of being source data for a very complex document.
- MDM - an optional first element of an M3M providing document title, table of contents and perhaps a template.
The core element of our data structure is the M1M.
You can think of it as a table with all the properties it might need.
It is likely to include a table (nested matrix or numeric matrix).
It can have accompanying text both above and below it; both can have multiple paragraphs and simple additional tables.
There can only be one complex table in an M1M because many of the properties only make sense in relation to one table.
Here are some of the properties of an M1M. All are optional.
- pvTXT - "text" - text to be printed before the table.
- pvTXTB - "textafter" - text to be printed after the table.
- pvM - "data" - the data matrix to be presented in a table.
- pvRT - "rowtitles" - titles for each row of the data matrix.
- pvCT - "coltitles" - titles for each column of the data matrix.
- pvMMO - "memocells" - data cells to be displayed freely between rowtitles and the data matrix.
- pvGPS - "rowgroups" - vector to group the data matrix rows.
- pvGH - "rowgrouptitles" - headings for horizontal groups identified by pvGPS.
- pvLCHL - "coltitlelevels" - level for column headings (if not all same level).
- pvTTL - "toprighttitle" - title to put in upper right corner of every page (the project title).
- pvCTTL - "toplefttitle" - title for top left of every page: time stamp, file used, calling WS/FN.
- pvDTS - "datetimestamp" - date time stamp for when the M3M var was produced.
- pvRTTL - "documenttitle" - title for the entire document (all pages), not same as pvTTL (the project title).
- pvSTR - "docstructure" - document structure, provides special handling features beyond those of the gallery.
- pvTTL3 - "title" - report title, displayed top center before the table.
- pvTTL4 - "subtitle" - title to put under pvTTL3.
- pvTTL7 - "titlenote" - title to put under pvTTL4 (not emphasized).
- pvTTL8 - "cornertitle" - title to put in corner over row titles and left of column titles.
- pvBTOT - "coltotals" - boolean: 1=show column totals; 0=blank column totals as they are meaningless.
- pvFLDP - "fieldchars" - field characteristics: width, decimals, datatype, justification, etc.
- pvVCOM - "" - variables common to all elements of M3M.
- pvICON - "" - logo, or other image(s) for the document or form.
- pvTBLV - "" - miscellaneous vector of programmer defined table parameters.
- pvFMV - "" - programmer defined parameters for printing reports.
- pvHDR3 - "" - section title to be placed before text in html "H3" style.
- pvHDR4 - "" - section title to be placed before text in html "H4" style.
- pvCRDT - "authorcredit" - literal vector for credit line (bottom left of every page) ("botlefttitle").
- pvBRTTL - "botrighttitle" - title to put in bottom right corner of every page.
- pvVAR - "varname" - name of the global array used to define the data matrix to be displayed in a table.
- pvIMAP - "" - map to guide use of this var, - "iMAP" - = - "incoming map" - for grid (by row/col range or by cell).
- pvCENH - "cellenhance" - grid control properties for individual cells.
- pvRTOT - "rowtotals" - actual data values to be placed in row totals at left (if not want plus summation).
- pvPRPT - "" - codes to identify standard acceptable manipulations for input arrays.
- pvINIT - "" - function or executable character string to initialize the data matrix.
We borrow generously from the work of others.
We use hundreds of utilities written by Bill Parke, Davin Church, and other very skilled APL programmers.
Adrian's illustrations for NewLeaf have frequently been adapted and his HTM2000 freeware
is the original source for a great deal of our HTML work.
Jonathan Manktelow gave us a good head start on using APLDRAW.
Eric Lescasse, Eric Landau, Steve Brooks and John Gregg can all see their work in our use of "Objects".
Eric Baelen, Fred Waid, Chris Lee and Jeff Pedneau will all find some of their work here.
And, going back to STSC's origins thanks to Al Rose, Murray Spencer and a bright young fellow named Don Link.
Lots of this is simply the informal sharing that goes in the APL community.
This effort will be helped as others become interested in working at this level of abstraction.
- Code quality
Since this work is the aggregate of work by many different people, code quality varies greatly.
Some, especially that written by Carl, is quite rough.
But we are comforted by Bob Smith's having said that APL is the best spec writing language in the world.
Much will be rewritten someday, but at least we'll know what it has to do because our specs work.
- Current Priorities for Continuing Development
- testing and debugging.
- changing the shape or dimension of arrays.
- help system.
- testing and debugging.
- User Defined Views -- this is the "Big Kahuna", the feature that will separate the men from the boys.
How will we make it easy and fun for the user to create views, forms and reports that suit his fancy ?
This paper will continue to be revised and is available on the internet at
Instructions and documentation for use of our drivers on the conference disk will be at that location.