Doco Home Hints Home
Marking up the Prototype HTML
Our conventions for choosing ID attribute names are described here.
All pages
- Form tags' METHOD
- Change METHOD="POST" to METHOD="GET" and vice versa,
where necessary.
- Javascript
- Does this page need a SCRIPT tag for Javascript?
- Stylesheets
- Does this page need any STYLE tags or stylesheet imports?
Query pages
Query pages gather the constraints for a database query. Generally, they
have little or no dynamic content.
- Date inputs
- Date inputs will usually be initialised to today's date. They need an
ID attribute.
- Pulldowns
- Pulldowns need an ID attribute if they are going to be populated from
the databases pulldown table.
Form pages
Form pages allow the user to edit a database record, or enter a new
record.
For adding a new record, the markup required is similar to the markup
for a Query page.
For editing a record, an HTML form must be filled with the content of the record. This
will require an INPUT tag (or SELECT, or TEXTAREA) for each editable field
of the database record.
- Accesses
- When editing a record, a database access will be required. See the
notes on Acceses below.
- Table ID Attribute
- Putting an ID attribute in a TABLE tag indicates to ConfigGen that the
dynamic nodes inside the table will be filled from an access (a unique
access).
- ObjectId input tag
- When editing a record, there needs to be a INPUT TYPE=HIDDEN containing
the records ObjectId. This will need an ID attribute.
- Going to a Commit page?
- If the next PO in the workflow is a
Commit page, check that the ACTION attribute of the FORM goes to the Commit
page (rather than the next visible PO).
Commit pages
Commit pages are generally not displayed to the user. However, the PO
conf for a commit page will be read by Pond when generating code, so Commit
pages do need markup.
- Form & ObjectId
- A commit page will need a FORM with INPUTs for all names the next PO
expects to find on the query string.
Usually, the next PO just expects one
name, whose value is the ObjectId of the new record.
List pages
List pages allow the user to select one record from a list, for the next
PO to operate on. This list will usually be in a TABLE, with each record
corresponding to a table row.
- Accesses
- When displaying recordss, a database access will be required. See the
notes on Acceses below.
- Table Row ID Attribute
- Putting an ID attribute in a TR tag indicates to ConfigGen that the
dynamic nodes inside the table will be filled from an access (a non-unique
access).
- ObjectId in Drill down image
- The prototype record will need an Anchor tag for the drill down. The
anchor tag should have an ID attribute for the records ObjectId.
- Form
- A list page will need a FORM with INPUTs for all names the next PO
expects to find on the query string. All the INPUTs in the FORM should be
TYPE=HIDDEN.
Usually, the next PO just expects one
name, whose value is the ObjectId of the new record.
Results pages
A Results page displays information from the database. It may display
multiple records, or a single record.
- Accesses
- When displaying recordss, a database access will be required. See the
notes on Acceses below.
- Table and Table Row ID Attribute
- Putting an ID attribute in a
TABLE or TR tag indicates to ConfigGen that the dynamic nodes inside the
table will be filled from an access. An ID in a TABLE tag indicates a unique
access ; an ID in a TR tag indicates a non-unique access.
Database Accesses
- Template ID
- When a database access may return several records (ie,
a non-unique access), part of the prototype HTML will need to be cloned for
each record. The node at the root of the template for the record will need
an ID attribute.
- ID Attributes indicating an access
- ConfigGen assumes that an ID attribute in some tag types indicate that
dynamic nodes within that tag's subtree will be filled from an Access.
A unique access is indicated by ID in: TABLE.
A non-unique access is
indicated by ID in: TR.
- Repeated elements in prototype
- The artist's HTML might contain
repeated sections, simulating multiple records from a database. All of
these, except the template, should be deleted from the prototype HTML.