are format strings- that is they can contain
variables (such as a server name). These variables can be evlauted at
compile-time or at run-time. For example, this allows for the definition
of email forms that can run seamlessly on multiple servers.
Instructions could read: Please fill-out this form and return it
to:
[Server-name]@[host].[subdomain].[domain]",
with the blanked parts filled out appropriately a run-time.
Instructions can be generic (that is, they will be written on the email
version of the form as well as the HTML and other versions of the form)
or they can be media-specific. The above example would be
media-specific, and it's HTML equivalent would be:
Submit the form Revert to initial values
Response functions are arbitrary LISP functions that take as
arguments a list of tags and responses and a stream through which they
can send something back to the client if needed. They are executed when
a response to the form they belong to is successfully processed by the
server.
A form has a list of queries. Every query has a set of
instructions (parallel to that of a form), a type and, sometimes, a
response function.
The type associated with a query is called a presentation
type. They determine what kind of answer is expected from the user.
Examples of types are integer, multiple-choice, date and state-keyword.
Types have parameters, such as upper bounds and lower bounds, list of
choices, etc. Every presentation type has two generic functions
associated with it:
- a presentation function (hence the name), responsible for rendering
(printing) the objects of that type. The different methods on that
function specialize on media. Currently, we implement HTML and Email
methods.
- an accept function which is responsible for validating the input.
The accept function is not specialized on media: specialized parsers
are responsible for getting the value of the answer, and the value is
used as the input to the accept function.
An illustrative example of a presentation function would that of the
multiple-choice type. In email, the type (multiple-choice ("Chocolate"
"Vanilla" "Other" "NA")) would be rendered as:
Please pick one of the following:
A. Chocolate
B. Vanilla
C. Other
D. NA
Valid answers: a letter between A and D.
=>ICE-CREAM=>
While in HTML, it would output HTML code which would look the usual way:
In turn the accept function will ensure that the answer is really A,
B, C, or D. Obviously, in more advanced form interaction environment
(such as the Web's) some of the validation is done through the
interface. With email, and for much more advanced presentation types,
accept functions running on the servers side are useful. Among the more
advanced type features that are supported or are in the process of
becoming so: cross-choices coherence rules, completion on partial
answers, etc.
Some queries have response functions. This stems from the distinction
between forms and atomic forms. Forms have queries which can
be answered independently of each other, in which case the queries
themselves have response functions. Atomic forms, on the other hand,
expect all queries to be filled out, answering only a few of the queries
would be meaningless- surveys are a type of atomic forms.
Finally, an important feature of the system is its organization by what
we call command interfaces. Command interfaces are essentially
namespaces (or packages), in which forms and queries are defined. Each
command interface has a library of uniquely named forms and another
library of uniquely named queries. While designing a form within a
command interface, a user can choose queries for his or her form. This
system of sharing queries across forms can help increase
productivity in authoring because some queries (such as "What is you
email address?") tend to occur in many different forms.