In the address book application there are two places where we need
to employ delete pages. The first delete page is used where we want to
allow the user to delete a single email address from the
information of a contact. The links to this page have been devised in the
contactdetail page and are displayed next to each email address in the body of
The second delete page whose links are displayed for every row in the contactlist page, is used to completely delete the information on a specific
contact. The above mentioned page should delete the associated rows from
both contact and
Similar to edit pages, the delete pages can not be accessed
directly. The user usually needs to click on a link displayed in some
other page to reach a delete page. A delete page receives as its parameter
the primary key of the row that should be deleted.
A delete page depends on a view page for its operation. When
the page receives the request for deletion, it uses the view page to display the
information that is going to be deleted. The view page displays the information
and provides a button which asks the user to confirm the deletion request.
Upon confirmation, control is returned to the original delete page and the
removal of the rows is carried out.
When the delete page receives the request, it first checks for
validity of the delete operation by examining the referential integrity constraints that
the developer has specified (this is described in the next section). Then
the delete page sends the parameter that it has received to the view page.
It is very important that the associated view page must be able to display the
intended information by receiving this parameter. For example if the
delete page is going to delete one row from table A, then the view page must
also expect as its parameter the primary key of a row in table A.
The emaildelete page is used to delete one row from the email
table. The definition of this page is shown in the following figure.
<?xml version="1.0" encoding="UTF-8"?>
It is seen that the definition is very concise as it only specifies the
target table and its primary key. The parameter that the page receives is
passed to the emaildetail page (a view page) where the single email address is
shown and a delete confirmation button is provided for the user. When the user confirms the
request, the delete page is activated again and this time the row is deleted.
Because of the similarity between this example and the example in the
next section, we don't provide the output for this page here.