This document describes the "CSE Checklist Ttool." The concept of this tool is that staff member users create records for instances of things that require coordinated actions by multiple staffers, after which the staffers mark off each item as it is performed. The tool displays each task with its status.
In order to allow a single tool to serve multiple applications, there is a separation of code from data. There is a general purpose "engine" shared by all applications, and there is a per-application configuration file that establishes the personality of the tool for that application.
These are the applications that use the checklist tool:
The tool is coded in Perl5.
The personality of this program is set via the URL, which contains the path of the configuration file, which is available to the program as the value of the PATH_INFO envar.
We store the persistant state in a Storable. The top-level data structure is an array of records. Each record is a hashref, with keys named by the values of the tag fields in @elements.
The details of the fields in the hash are controlled by the @elements data structure, which lives in the configuration file that is necessary to give this tool a personality. For the most part, each item in @elements corresponds to a field in the hash (except for 'section' and 'instr' types).
The element types, and their attributes, are:
Type | Semantics | Attributes |
---|---|---|
text | a text input field | name, tag, size, required, email, valid, ordered, indexed |
date | a date input field | name, tag |
action | also a date, but implies an action | name, tag, indent |
caction | yes/no radio buttons | name, tag |
section | immutable text with leading HR | name |
instr | immutable text | name, collapse |
synthetic | text synthesized by calling the function $_->{display} | display |
Attribute | Semantics |
---|---|
tag | single-token handle on the element |
name | displayed label |
size | for 'text' elements, the field width |
required | a required field |
an email address-- include mailto links | |
valid | a regular expression that valid values must match |
indexed | whether this element is a column in the index |
ordered | whether users can sort the index on values of this field |
We worry that a record could lose data if one user submits data between the time that another user loads the edit screen and saves their own data. Therefore, we store a last-modified timestamp on each "record" (that is, each element of the array in the Storable), and store the time that an edit screen was built in a hidden field in the edit screen. We won't store data for a record if it was modified more recently than the edit screen was built.
This program implements a test and a production installation, distinguished by the name of the script: it the substring "test" is found in the script name, it's running in test mode. Currently, that has no effect whatsoever other than to set the unused variable $debug, but it can come in handy for debugging. Because test mode is controlled entirely by the script name, nothing needs to be changed in this file to move to production mode (other than the filename itself).