Papers in PDF format

4.1 State and the Swap
State can be added to Web database applications through the addition of a table that we call the “swap” (since
it is used to temporarily store form contents). Through use of the swap, tag/value pairs can be associated with a
specific user and the screen they are currently accessing. The Swap table contains five columns: Username,
Screen, Type, Tag, and Value. The Username must be a unique identifier, the Screen is a unique name given
to each input form in the Web interface, the Type is used to specify different types of value pairs (for example
form data or error messages), and the Tag and Value fields are used to record the state of the system (for
example form field names and the data they contain).
When a user completes a form, the tag/value pairs sent to the CGI script are saved in the Swap table. If some
form data form turns out to be incorrect, that specific region of the form can be reconstructed with appropriate
help or error messages, leaving the remainder of the data stored in the swap. Also, if a user partially completes
a form, but then presses a button to request help, by saving the form data to the swap, the form can be restored .
More importantly, the swap can be used to protect important data that should not be modified by the user. If a
user modifies a row in a database table, it is important to retain the primary key of that row so that an update
can properly be executed. If the primary key of the row is kept in a hidden field, the HTML code may be
hacked so that the destination of the information is changed. By keeping the primary key in the swap, such a
modification is impossible. Therefore the swap ensures the security of the application data.
4.2 Maintainability and the Lifetime of an Input Form
Code reuse can significantly reduce development time and cost. This can be through modularization of the
tasks necessary to process an input form. The following steps are what we call the “lifetime” of a form:
1. Preparation - If the form is used to edit existing data, the necessary queries are made here. The results of the
queries are saved into the swap to be used when the actual form is created.
2. Displaying the Form - Here the form is generated. If data for the form exists in the swap, then the data is
used as the default values for the form objects. If error messages exist in the swap, these messages are
displayed in appropriate places on the form.
3. Check the User's Input - If the user makes a request for a help screen, we display the help screen and then
return to step 2. If there are errors in the data, we save error messages into the swap and then return to
step 2. Otherwise we continue to the verification screen.
4. Verification Screen - If desired, the data that the user entered can be redisplayed for verification. If the user
wishes to change something, we return to step 2. Otherwise we continue to step 5.
5. Update the Database - Here the data is removed from the Swap and entered into the Database. A screen is
displayed that tells the user that the data has been committed to the database.
By identifying these elements common to many forms, routines can be written to encapsulate these steps. If
separate CGI scripts are used for each step, scripts will not submit data to themselves. Our experience has
found self-submitting scripts to be difficult to debug or modify and so they should be avoided at all costs.
5. New Developments