I omitted a *lot* of DECFORMS-specific information (2/3!) from this report
but have
left in analysis that makes it clear what this product/standard did right
and wrong,
especially when compared to object-oriented approaches. Glossary, terminology,
etc. are here for those who are not so familiar with forms management in
general.
The detailed feature list, which might provide a laundry list of features
for HTML forms,
is in my next (separate) message.
The major innovation of DECFORMS/FIMS was that field and form level
validation (e.g.
ranges of values, two values that are constrained by each other, etc.) are
handled by
the form itself. Also, runtime conditions can determine whether certain
features appear.
My main criticism of it was that it fit poorly with object-oriented
application interfaces, and
it didn't really protect application developers from dealing with type
differences in
languages (a problem actually solved by the OO APIs, such as CORBA/OLE/CGI
today)
Unfortunately incorporating field level validation starts to turn a form
into a spreadsheet,
with equivalent complexity in the formulae, but if CGI-BIN functionality is
ultimately to be
retrieved from some repository via a URI, I see no problem with this.
Inter-field validation
is harder but if the form is backed by some kind of a data structure all of
the CGI-BIN
scripts can refer to it, and a final validation check can be made before the
form is actually
accepted.
-----------------------------
(excerpt from DECFORMS/FIMS report of summer 1991)
Strengths
---------
- form handles entire interactive dialog with the user
- form can validate and filter input
- form can adapt to runtime conditions
- multiple interfaces can be developed for the same application
- exchanges data with almost all VAX programming languages
- layered architecture shields developers from unnecessary details
- choice of binding mechanisms increases flexibility
- runs on the entire VAX/VMS server and VT terminal product lines
- provides upgrade path from prior VAX form products, FMS and TDMS
- rich graphic Forms Development Environment, including converters
- complies with proposed CODASYL/ANSI/ISO forms standard
Limitations
-----------
- currently (version 1.3) available only for VAX
- lacks library support for common/recommended styles
- very specific dividing line between form and application
- communication between application and form can be complex
- exported data types do not hide difference between languages
- internal interfaces subject to change as FIMS evolves
- external interfaces a poor fit with object-oriented ACA model
Relationship to other markets:
Those who need to support a wide variety of different terminal devices
and users with one program, keeping front and back end separate, can
approach the problem in a variety of ways. The range of products
available reflects those choices:
Object request brokers (as in HP's NewWave, DEC's ACA Services and the
OMG standard combining both) allow developers to divide a system into
many separate parts that communicate efficiently over a network.
User interface toolkits (including C libraries like XVT and C++
frameworks like ImageSoft CommonView, AT&T/Solbourne OI, and Apple
MacApp) allow developers to build a sophisticated user interface once
without rewriting it for each presentation device/platform on which it
is used. Applications are designed as a set of responses to events.
Few support character terminals, or multiple programming languages.
Distributed forms management products solve both problems to a limited
degree, with a single product. They support only a simple kind of
interface (i.e. a form) and a simple kind of client-server communication
(i.e. form to application and back again). They do not help developers
support interactive graphics or break the application up into more than
two (front end, back end) pieces.
This relatively large niche market is occupied by unique products like
DECforms, other forms packages (e.g. SQLforms, JetForms), somewhat less
specialized language products such as 4GLs and databases, and the very
general tools mentioned above.
Language, platform, and capability restrictions prevent most of these
products from competing directly with DECforms. However, combining UI
and client-server tools is a powerful alternative to a forms system.
DEC proved this by basing All-in-1 Phase II directly on ACA, bypassing
DECforms even though the original All-in-1 was based on FMS. DECforms
and ACA can also coexist, as they do in DEC's COHESION CASE environment.
Decision Points
---------------
product requirement comment
------- ----------- -------
DECforms FMS migration converter provided
DECforms TDMS migration converter provided
DECforms ANSI/ISO compliance DECforms is sole FIMS implementation
DECforms low-cost delivery runtime expensive for small groups
DECforms support available DEC offers services, no third party
DECforms stable product will evolve due to standards process
DECforms standard product yes, may lose out to OO approaches
DECforms consistent UI style good guidelines, no libraries yet
DECforms globalization multi-language forms and options
DECforms simple forms definition layered (editor, IFDL, escapes...)
DECforms customized UIs most UI changes can be made in IFDL
DECforms modules and binding several mechanisms, can be complex
DECforms programming language all major VAX languages supported
DECforms CDD/Plus integration improving, area needs more standards
DECforms ACMS, DECintact support available but callout is synchronous
DECforms LSE support diagnostics, compile and review
DECforms distributed system promised in v1.4 (NAS protocols)
DECforms Ultrix support promised in v1.4 (Fortran, C only)
DECforms X terminal support promised in V1.4
DECforms VT terminal support excellent, covers whole product line
DECforms non-DEC workstations supported only as VTxxx emulators
DECforms VAX server support excellent, covers whole product line
DECforms non-DEC servers not supported
5. SPECIFICATION (DECforms)
Intro:
DECforms is DEC's "single form solution for the 90s" and implements the
CODASYL FIMS specification which is accredited by ANSI and ISO as a
draft standard. It is a true user interface management system (UIMS):
it manages dialog with the user, presenting a user interface that is
defined in a specialized language/notation, using interactive tools.
Developers can build several form-and-menu-based user interfaces to the
same application, which can be substituted for each other freely at
runtime. These communicate identically with the application regardless
of terminal, user, or form characteristics in effect at runtime.
Terminology:
"Form Interface Management Standard" (FIMS)
CODASYL specification for building form- and menu-based user
interfaces. Accredited by ANSI and ISO as a draft standard. DECforms
implements the 1988 draft.
"Independent Form Description Language" (IFDL)
A semi-procedural language to describe forms in FIMS and DECforms.
"Form Manager"
The DECforms runtime engine - handles the form's interaction with
the user, the terminal, and the application program. Comparable to the
FMS "Form Driver" or TDMS "Request Processor".
"Form Control System" (FCS)
The FIMS term for a Forms Manager.
"Forms Development Environment" (FDE)
Tools for building, editing, and converting forms.
"session"
A connection between a terminal and an application using a form.
"action"
An actual user action initiated by the terminal operator.
"request"
One of six routines used by application programs to control forms:
request description
------- -----------
enable create a session and enable a form.
disable end the session
send move data from the application program to the form.
receive move data from the form to the application program.
transceive combined SEND/RECEIVE (for network efficiency)
cancel cancel all outstanding requests
"event"
An action (by the user) or request (by the application).
"response"
The Forms Manager's (programmed or default) response to an event.
"display device"
A two-dimensional output device (e.g. a VT220 terminal).
"screen"
The actual display area of the display device (e.g. 80x25)
"display"
The rectangular area on a display device that is available to a
particular form (e.g. 80x24)
"viewport"
A rectangular section of the display area. Convenient for naming
(possibly overlapping) areas of the display. Similar to a window.
"panel"
A rectangular panel with visible elements (as listed in the table
below). What VAX FMS and TDMS refer to as a "form". Similar to a
dialog box. A panel is displayed in a viewport of equal or larger
size.
element description
------- -----------
literals background items that do not change while the
application is running
fields changeable items
icons literals that support cursor positioning and selection
groups logical collections of fields, icons, and
literals (often used for array structures)
attributes field validation, highlighting, etc.
"layout"
A group of panels that, taken together, constitute a complete user
interface to a program - e.g. all panels in Spanish, or all bitmap
panels for use on an X terminal. Use of different layouts can insulate
application programs from end-user or terminal characteristics.
"procedural escape"
A callout from an IFDL form to another programming language.
"form data item"
A form variable with a unique name and data type. May be
displayed in a panel, passed between form and program, or used
internally in form processing. Persists for one session only (from
'enable' to 'disable') and is therefore similar to a local variable.
"form data"
The complete set of variables contained within the form.
"form record"
A structure of variable fields in the application program (e.g. a
Pascal record or C struct). Stores data to be transferred to/from the
form. An instance of a form record description.
"form record description"
A mapping between form data (visible to the form) and the form
record (visible to the application program). Usually invisible.
"form"
The complete forms-and-menu-based user interface to an application
program, including panels, form data and form record description. A
DECforms form includes the entire user interface specification, possibly
including validation, several layouts corresponding to different display
devices and/or natural languages, form-specific processing in IFDL and
procedural escapes to other languages.
Craig Hubley | Business that runs on knowledge +
Craig Hubley & Associates | needs software that runs on the net +
mailto:craig@hubley.com 416-778-6136 FAX 416-778-1965
Seventy Eaton Avenue Toronto ON M4J 2Z5 Canada