What XPage Is
How It Works
A Case Study
View Pages
      Multi-Row
      Single-Row
      Hybrid
Insert Pages
      Hybrid
      Single-Row
Edit Pages
Search Pages
Delete Pages
      Single-Row
      Hybrid
Overall Features
      Page Features
Engineer's View
      System Catalog
      Page Types
      View Pages
      Insert Pages
      Edit Pages
      Search Pages
      Delete Pages

SourceForge Logo

 

Hybrid Delete Pages

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.

Referential Integrity Constraints

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.