This chapter describes the basic mechanisms and features of the web user interface generated by ERW. It is not an end-user manual.
As we mentioned before, ERW lets you edit instances of an entity-relationship schema. That is, it lets you create and delete entities and relationships, and change their attributes.
Each entity has an associated form, from which the user can modify its attributes and incident relationships. To access the form, the user must select the entity from the main list: it is a list of all existing entities. This list can be filtered in several ways, and is generated by the script list.php.
Once the user selects an entity for editing, a new window is opened that contains HTML input controls for attributes (text inputs, text areas, radio buttons etc.) and a number of complex structures for editing relationships. The content of the window is generated by the script form.php.
The rationale behind the editing of relationships is that you have a white-background list, containing the current relationships; and, immediately below, a grey-background list of entities that could be used to create new ones. Suitable buttons allow the user to perform relationship editing. For convenience, buttons that allow to create new entities or modifying existing ones are also allowed, but they can be inhibited.
Editing relationship attributes is also fairly easy: there is a set of input controls under the list of relationships. All new relationships get the attributes currently displayed. Moreover, whenever the user clicks on an existing relationship, its attributes are loaded into the controls (in this way it is easy to copy the attributes of an existing relationship). If the user wants to modify the attributes of an existing relationship, he or she has just to click on the relationship, modify the controls and click on the "Apply" button, which will apply the current values.
By default, ERW displays first all attributes, then filesets, and
then relationships. Attributes are listed in the same order as in the ERL
file; they are prefixed with their label, and the label is embedded in a
STRONG HTML element if the attribute
is mandatory. Of course, this can be changed using custom forms.
If an attribute cannot be modified, because it is read only, it
is displayed in a different manner: HTML input control get their
READONLY attribute set, whereas lists just
display the available elements (e.g., relationships) on a grey
Often browsers do not support the
Finally, the user can select among four buttons (any of which can be inhibited) to finish editing. "OK", as expected, save changes and closes the form. "Save" commits changes, but leaves the form open for further editing. "Save & Clone" commits changes, and creates a clone of the current entity that can be further edited and saved (this is most useful when doing repetitive data entry). Finally, "Cancel" will forget all changes.
You can tweak the default.php script, which
generates the CSS style sheet, to change some details. In particular,
DIV elements of class
listborder surround lists: by choosing, for instance,
the value scroll instead of hidden
for the overflow CSS attribute you can display lists
with scroll bars that let the user scroll to see long labels. Moreover, the
editable attribute of the
allows you to select from which side the user can edit relationships.
The main ingredient in the design of ERW's web interface is stateless editing. HTTP is a stateless protocol, and, as such, is not prone to support stateful interaction with a server (this is usually achieved with a mix of cookies and server sessions imposed over the protocol). ERW is designed to let the user edit freely a database recording no information server-side. All state related to the modification made by the user is stored client-side, so that the connection to the database is truly stateless.
This approach has a number of advantages: in particular, it adheres to the principle of least surprise: web users are by now accustomed to the idea that closing abruptly a web page (or even killing the browser), even in the middle of a multi-page form submission, will result in no changes being recorded server-side.
Indeed, any web form is an example of stateless editing: input controls store client-side the current choice of the user. The situation, however, is completely different when we take into consideration relationship editing.
The user, before submitting any information to the server, should be able to add relationships, delete old or new ones, and edit their attributes, without storing state on the server. This requires a completely different approach, as the state of input controls is not sufficient to store this information.