The User Interface

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.

You can help the user to understand what's going on my making good use of the help attribute for attr and leg elements.

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 background.

Warning

Often browsers do not support the READONLY attribute on sophisticated controls, such as drop-down lists. Of course, ERW will just discard any changes, but the user may not be aware of this fact.

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 leg element allows you to select from which side the user can edit relationships.

Stateless Editing

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.

ERW uses JavaScript scripting and the W3C DOM to alter the appearance of the form, showing how relationships are added or deleted, and how their attributes are modified. All these data are stored in the JavaScript state of the browser. Suitable JavaScript code interacts with the database presenting the user with a modified view, which however does not really exist server-side. When the user has finished with editing, and submits the form, the entire JavaScript state of the form is suitably serialised and sent to the server. The PHP run-time environment on the server locks the part of the database that is affected by the changes, checks that no integrity constraints are violated, and performs the changes. If anything goes wrong, the user is presented again with the form that was submitted: using the serialised client state, the server is indeed able to completely rebuild the JavaScript state of the submitted form.