ACS Templating Requirements

by Karl Goldstein, Christian Brechbühler, Peter Su, and Yonatan Feldman

I. Introduction

The following is a requirements document for the ACS Templating System version 0.5. It has also been called Karl's Templates, the Dynamic Publishing System (DPS), and Stencil. The official package name for the system is now acs-templating.

II. Vision Statement

On websites of sufficient size, a consistent look and feel (the UI, or user interface) for users is important, while for site publishers and administrators, de-coupling the UI from programming allows for easier maintenance and more efficient workflow. Thus the ACS 4 Templating system provides mechanisms that allow programmers and graphic designers to work independently of each other. Templates specify the layout of the page separately from the dynamic content of the page. Graphic designers work primarily on the layout, that is the template, while programmers work primarily on a script or program that generates the dynamic content that fills the blanks in the template. In addition, the templating system provides a way to use a single layout specification for the majority - if not all - of a website's pages, so the overall layout of a site can be more easily administered.

III. System Overview

The templating system provides:

IV. Use-cases and User-scenarios

The template system is designed to be used by two classes of users: programmers and designers. In bulding a web site, programmers are generally responsible for defining and implementing the application logic of the site, while designers are more responsible for the presentation. Generally speaking, the application logic generates data for the presentation to display to the user. The template system must provide mechanisms that supports both of these tasks and allows the designer and programmer to work seperately, but for their work to be combined at runtime into something that the user sees as a single page.

Thus, pages are naturally split into two parts. The logic part executes application logic and generates data, and the presentation part that specifies the layout of the page and so on.

What is needed is:

  1. A notation and API for the programmer specify the application logic and to generate the data to be displayed. In ACS, we call the data that we wish to display a data source or page property. Application logic is driven by the inputs the page gathers from the user request (e.g. the HTTP request), and the computation that the page must perform on this input. This computation will generally create and populate the data sources and page properties. Data sources tend to be connected to database queries, while page properties can be defined by any arbitrary computation.
  2. A notation and API for the designer to specify how the data sources and page properties will be presented to the user. This notation will generally take the form of some kind extended HTML.
  3. A mechanism for communicating the data sources and page properties from the logic part of the page

Jane Programmer writes a page contract and a draft template, that uses the promised page properties. Joe Designer takes that template and makes it look nice, using his design skills and HTML literacy. Meanwhile Jane Programmer writes code to generate the page properties, typically by querying the database. When both are done, the page is ready for Jim User, who requests it using his web browser.

Alternate scenario: Judy Designer is familiar with the template system. She starts directly from a defined page contract, so Jane Programmer doesn't need to write the draft template.

V. Related Links

VI.A Functional Requirements

VI.B Non-functional Requirements

VII. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 8/23/2000 Yonatan Feldman
0.2 Merge with previous docs 8/25/2000 Christian Brechbühler
0.3 Edited, reviewed, pending freeze 8/28/2000 Kai Wu

yon@arsdigita.com
Last modified: $Id: requirements.html,v 1.1 2001/03/13 22:59:27 ben Exp $