About XPage
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

 

Delete Pages

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 page. 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 email tables.

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.

Single-Row Delete Pages

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"?>

<page type="delete">
  <redirectto>emaildetail</redirectto>
  <title>Delete Email</title>
  <icon>contactdelete.gif</icon>
  <top>
    <targettable>email</targettable>
    <primarykey>id</primarykey>
  </top>
</page>

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.