templating, forms, navigation, etc.
part of the ArsDigita Community System
by Philip Greenspun
This document was written on February 28, 2000. It reflects months of
wrangling with trying to find the right abstractions for a whole range
of stuff including
- separation of programmers from graphic design changes
- distributing authoring and editing out to non-technical people
- changing site-wide look and feel by making a change in one place
- standardizing the presentation for entry/editing and validation of
elements in the database
- taking the next step in multi-lingualism beyond the June 1999 system (i.e., "getting English
annotation out of programs" or "letting a designer pull multiple rows
out of a datasource and annotate each row with some local language")
- getting beyond HTML output; people using cell phones to visit an
ACS-backed site will certainly not want the complex HTML pages produced
by ArsDigita's customer's designers and they may not want HTML at all!
(e.g., they might raw XML info; certainly co-brand partners will want
just the XML)
Here are some good high-level goals:
- programmers should be able to work in a standard text editor, such
as Emacs, rather than using a database + Web forms approach
- if they so choose, programmers should be able to stick to a
rat-simple everything-in-one-file approach a la Perl CGI, AOLserver
, AOLserver ADP, Microsoft ASP, Java Server Pages (JSP); for simple
stuff it is often much much easier to debug a system where you don't
have to chase down four separate files to find the code
- we should not have to do a major port of all modules of the ACS at
once and yet we may want all the modules to be able to take advantage of
at least some of the new services and abstractions
- we should not rely on the template builder to personalize a page or
screen out information for which the connected user does not have
permission; no data should be available to the template unless the
connected user is authorized to view those data
- we should not create our own language(s); Creating a new language
requires also creating a tremendous amount of ancillary tools (e.g.,
debuggers), educational materials, etc. Consider that Microsoft has
never created a new language! IBM has not done so since the 1960s
(PL/I; they did Fortran in the 1950s). Sun has done one (Java). In the
Web world, the only company that has come close to establishing a new
language is Allaire with Cold Fusion. Cold Fusion has not been
well-received by professional programmers or anyone attacking new
challenges.
- #1 most important goal: if we have powerful abstractions for
encapsulating decisions made about overall site look, navigation, etc.,
these abstractions should be available to developers programming in any
style (, .adp, Java inside Oracle, producing XML, fancy
templating, etc.). One should not have to buy into any one particular
development style in order to take advantage of the abstractions.
Development Styles that We Want to Support
- a page producing a complete HTML document
- a page producing an HTML fragment, intended to be wrapped in a
site-wide or section-wide master template
- a page producing a plain text document (to be served with MIME
type of plain/text)
- a page producing an XML document, which will later be rendered
with a style sheet (XSL or our own thing) if the client does not want to
accept XML
- a .adp page that evaluates to a complete HTML document
- a .adp page that includes lots of other .adp files and then
evaluates to a complete HTML document (this is the AOL/DigitalCity
method of development)
- a Karl-style .spec file that produces a data structure to be
rendered with a Karl-style augmented ADP template (breaks the "no
creating new languages" rule above, but Cynthia and Karl like it)
Form Generation and Processing
We need metadata inside Oracle (so that it is available to all clients,
whether AOLserver or other) that, for any column in the database says
- what its pretty name is
- how it is to be presented to the user for form input (e.g., text
box, textarea, radio buttons)
- if a radio button or checkbox presentation, what the legal choices
are (the survey-simple.sql data model may be useful here)
- what validity tests are to be performed on the user's input (it
would be nice to use an interpreted language like Tcl here so that we
are fully general but probably it is best to restrict ourselves to
things that can be easily evaluated within Java within Oracle)
We need a full Java API to these metadata, e.g., "give me the empty
form" or "give me a form stuffed with the user's previous entries" or
"validate these inputs for me".
For data that we're trying to collect from the users, we need a little
language in which to express
- the user needs to be asked to give us particular info (either
table/column or something more abstract like "home_address") before
performing some operation
- the user needs to be forced to give us particular info (either
table/column or something more abstract like "home_address") before
performing some operation
Note that the "user needs to be asked" implies that we have some kind of
log so that we don't keep reasking a question that the user has refused
to answer. We want a full PL/SQL or Java API to this stuff.
philg@mit.edu