|
It was explained in the previous sections that the view pages and
insert pages can handle information from two tables. This is also true for
the delete pages, as they can simultaneously delete related information from two
tables. The following figure displays the definition of contactdelete page
which can delete information of the contact together with the associated email
addresses.
<?xml version="1.0" encoding="UTF-8"?>
<page type="delete">
<redirectto>contactdetail</redirectto>
<title>Delete Contact</title>
<icon>contactdelete.gif</icon>
<top>
<targettable>contact</targettable>
<primarykey>id</primarykey>
</top>
<body>
<targettable>email</targettable>
<foreignkey>contactid</foreignkey>
</body>
</page>
The <redirectto> tag specifies that for asking the user to confirm
deletion, the
parameter that the page has received should be sent to the contactdetail page to
display the contact information. Based on the definition of the
contactlist page, that page send the value of the id attribute for the selected
row to this delete page. So by sending this same parameter to the
contactdetail page, it will correctly display the information on the intended
contact.
In the <top> section, the <targettable> and <primarykey> tags
specify the contact table and the id attribute, respectively. Since this
is a hybrid delete page, the <top> and <body> sections exist simultaneously.
The <body> section introduces the email table as the target table. Also
the <foreignkey> tag specifies the contactid attribute which is the foreign key
of the email table. Definition of the two tables and their related
attributes is quite similar to the contactinsert page whose responsibility was
inserting a new contact together with his/her email
addresses. Clicking on one of the Delete links in the contactlist page
will take the user to a page similar to the one shown in the following figure.
Contact delete page in browser
In fact this is the output of the contactdetail page. But upon
confirming the request, the contactdelete page is reactivated and the rows are deleted.
Delete pages are able to check the validity of the delete
operation before deleting the rows. If there may exist references from
other tables to the information that is being deleted, the developer can define
appropriate constraints that prevent the page from deleting rows that are
referenced. That is, if
in some other table there is some attribute which is a foreign key for the
target table of the page, the system will make sure that the row that is being
deleted is not referenced from any of the rows in the referencing table.
For example, if we were to keep track of every
phone call made for each of the contacts in our sample address book, we had to create another table for
storing call information. That table, named "calltrack", must have a
foreign key referencing the contact table. If we call that foreign key
attribute "personid", then we should change definition of the contactdelete page
according to the following figure.
<?xml version="1.0" encoding="UTF-8"?>
<page type="delete">
<redirectto>contactdetail</redirectto>
<title>Delete Contact</title>
<icon>contactdelete.gif</icon>
<top>
<targettable>contact</targettable>
<primarykey>id</primarykey>
<constraints>
<constraint>
<table>calltrack</table>
<foreignkey>personid</foreignkey>
<vilationmessage>Please first delete call information for this
contact.</violationmessage>
</constraint>
</constraints>
</top>
<body>
<targettable>email</targettable>
<foreignkey>contactid</foreignkey>
</body>
</page>
The referential integrity constraints are defined inside the
<constraints> section. For every table that has references to the target
table, the developer should include one <constraint> tag which in turn encompasses the following
tags:
-
<table> tag specifies the name of the table that references
the target table
-
<foreignkey> tag denotes the name of the foreign key
attribute
-
<violationmessage> is the message shown to the user when the
constraint is violated
When the user requests the delete page, before redirecting to the
associated view page for displaying the
information, the delete page checks every table defined in the <constraint> sections to
make sure no references exists to the row that is going to be deleted. If some
reference exists in any of the tables (for example if there is any row in the calltrack table whose personid attribute matches the primary key of the selected
row in the contact table) the delete confirmation button is not displayed;
instead the violation message defined by the developer is displayed to the user,
telling him/her why the deletion is not possible. |
