templating, forms, navigation, etc.

• 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)

• 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 .tcl, 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 (.tcl, .adp, Java inside Oracle, .tcl 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 .tcl page producing a complete HTML document
• a .tcl page producing an HTML fragment, intended to be wrapped in a site-wide or section-wide master template
• a .tcl page producing a plain text document (to be served with MIME type of plain/text)
• a .tcl 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

• 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)

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