Page Bottom  Documentation

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.

  1. Scope and Principles of Design

    1. 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.

      1. APL2000 grid control
        The high degree of interactivity and performance speed using the APL2000 grid control is very important.
      2. NewLeaf
        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.
      3. Excel
        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.
      4. 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.

    2. 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).

    3. 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.

    4. Views, Forms & Reports
      We view these three terms as interchangeable because each is generated from the same structure of source specifications.
      1. 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.
      2. 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.

    5. 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.

    6. 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.

  2. How It All Hangs Together

    1. 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.

    2. 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.

    3. 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.
      • 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 code changes.
      • 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.

    4. 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.

  3. 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.

    1. Specific Data Structures
      This describes our data structure and definitions important to the data structure.
      1. 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".
      2. PVM - Property Value Pairs arranged as a two column matrix (the kind of PVP we use).
      3. M1M - a PVM with a specific set of properties.
      4. M3M - a vector of M1M's, capable of being source data for a very complex document.
      5. MDM - an optional first element of an M3M providing document title, table of contents and perhaps a template.

    2. Properties
      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.

      1. pvTXT - "text" - text to be printed before the table.
      2. pvTXTB - "textafter" - text to be printed after the table.
      3. pvM - "data" - the data matrix to be presented in a table.
      4. pvRT - "rowtitles" - titles for each row of the data matrix.
      5. pvCT - "coltitles" - titles for each column of the data matrix.
      6. pvMMO - "memocells" - data cells to be displayed freely between rowtitles and the data matrix.
      7. pvGPS - "rowgroups" - vector to group the data matrix rows.
      8. pvGH - "rowgrouptitles" - headings for horizontal groups identified by pvGPS.
      9. pvLCHL - "coltitlelevels" - level for column headings (if not all same level).
      10. pvTTL - "toprighttitle" - title to put in upper right corner of every page (the project title).
      11. pvCTTL - "toplefttitle" - title for top left of every page: time stamp, file used, calling WS/FN.
      12. pvDTS - "datetimestamp" - date time stamp for when the M3M var was produced.
      13. pvRTTL - "documenttitle" - title for the entire document (all pages), not same as pvTTL (the project title).
      14. pvSTR - "docstructure" - document structure, provides special handling features beyond those of the gallery.
      15. pvTTL3 - "title" - report title, displayed top center before the table.
      16. pvTTL4 - "subtitle" - title to put under pvTTL3.
      17. pvTTL7 - "titlenote" - title to put under pvTTL4 (not emphasized).
      18. pvTTL8 - "cornertitle" - title to put in corner over row titles and left of column titles.
      19. pvBTOT - "coltotals" - boolean: 1=show column totals; 0=blank column totals as they are meaningless.
      20. pvFLDP - "fieldchars" - field characteristics: width, decimals, datatype, justification, etc.
      21. pvVCOM - "" - variables common to all elements of M3M.
      22. pvICON - "" - logo, or other image(s) for the document or form.
      23. pvTBLV - "" - miscellaneous vector of programmer defined table parameters.
      24. pvFMV - "" - programmer defined parameters for printing reports.
      25. pvHDR3 - "" - section title to be placed before text in html "H3" style.
      26. pvHDR4 - "" - section title to be placed before text in html "H4" style.
      27. pvCRDT - "authorcredit" - literal vector for credit line (bottom left of every page) ("botlefttitle").
      28. pvBRTTL - "botrighttitle" - title to put in bottom right corner of every page.
      29. pvVAR - "varname" - name of the global array used to define the data matrix to be displayed in a table.
      30. pvIMAP - "" - map to guide use of this var, - "iMAP" - = - "incoming map" - for grid (by row/col range or by cell).
      31. pvCENH - "cellenhance" - grid control properties for individual cells.
      32. pvRTOT - "rowtotals" - actual data values to be placed in row totals at left (if not want plus summation).
      33. pvPRPT - "" - codes to identify standard acceptable manipulations for input arrays.
      34. pvINIT - "" - function or executable character string to initialize the data matrix.

  4. Conclusions

    1. Collaboration
      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.

    2. 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.

    3. Current Priorities for Continuing Development
      1. testing and debugging.
      2. changing the shape or dimension of arrays.
      3. help system.
      4. RainPro.
      5. ...
      6. ...
      7. testing and debugging.
      8. 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.

horizontal line
to home page e-mail Page Top