Copyright © 2002 The Glasgow Worldcon 2005
January 19th, 2002
Table of Contents
This article describes the overall architecture of the Convention Database project.
Lorem ipsum dolor sit amet...
This document is a work in progress!
Atoms are Java objects that contain indivisible items of information such as a single column in a single database row, a single input field in a web form, or the value of a single attribute of a single element in an XML document.
Besides accessors for setting and retrieving their value, atoms have methods for validation and normalization. Validation verifies the atom's syntax and internal consistency, while normalization reduces it to its canonical representation, by removing leading zeroes from a decimal number, for instance, or superfluous whitespace from a string.
A context is a set of named atoms which serve as parameters for a high-level function such as a dialog page or a transaction.
A nested context has a pointer to a parent context (which may itself be a nested context) from which it looks up atoms which it does not itself contain. Adding or removing atoms in a nested context does not modify the parent context, so all changes made to a nested context can be undone simply by clearing it.
These are the basic operations (retrieval, addition or modification of information in the database) on top of which the applications are built.
Dialogs are the backbone of the core library's user interface component. A dialog (also called a flow) consists of a set of interconnected pages, each of which has a list of inputs (named and labeled atoms) and actions (labeled “submit” knobs), and a set of rules for selecting the next page. Page transitions are only allowed once all inputs for the selected transition have been successfully validated.
Dialogs normally present one or more reports, and often culminate in a transaction.
Each flow is described in a separate XML file, which is translated into Java source code at build time. A separate class is generated for each page, plus one for the flow itself.
Ultimately, flow and page classes will be generated at runtime using the Jakarta BCEL package or some similar Java bytecode generation package.
Since dialogs are a mostly abstract concept, some interface code is necesasry to actually present information to the user and obtain the required input.
The foundation for these drivers is the Conversation interface, which declares an API for constructing a page (by setting its title and adding text, inputs and actions to it), presenting a page to the user, and registering a listener that will be notified when the user has filled out the form and selected one of the actions.
The Servlet driver is a Java Servlet that implements the Conversation interface, plus some glue code to select and load the correct flow and page based on the request URL or the CGI parameters.
Initially, the Servlet driver will render pages by generating simple HTML forms at request time, but in the long run, it will use a template engine such as Jakarta Velocity to load and evaluate stored templates.
These are convenient tools that are not strictly required for the operation and maintenance of the Convention Database, but facilitate certain common tasks.
The dialog composer is a standalone application that provides a graphical interface for creating, editing and testing dialog flows.
The SQL designer is a standalone application that provides a graphical interface for creating and editing SQL schemas. It is equipped with a number of import and export filters, allowing it to not only read and write its own custom XML format, but also parse and generate raw SQL code, and work directly on live SQL databases using JDBC.