Features

Most features of the tool were introduced in the pages developed in preceding sections.  We present here a summary of the overall features of XPage as well as the features of each pages type.

Conciseness

It may seem that the generic scripts that are executing the pages with their versatile capabilities must be very complicated.  However, no more than 1400 LOC is used to implement the four generic scripts.  Despite the small files, the examples in the demo site demonstrate that it is possible to develop real-world applications using the tool.  There is no claim that this tool is able to answer all the needs, however summarizing the basic functionalities required for implementing data-intensive applications (or information systems) in a few generic program files has made it possible to implement new features by just modifying the generic files.  So every feature will be developed just once and used forever.

Abstraction

Using the XML language for describing the pages provides a level of abstraction between the responsibilities of the pages and their implementations.  Examining the syntax used in defining the pages reveals that page definitions only describe the data that are dealt with in the pages and the format in which they is presented.  This abstraction allows the developer to focus on the data model of the application when developing the pages.

It also allows for extending the tool to other environment and platforms.  For example if we decide to translate the XML definition to ASP scripts instead of PHP scripts, it is possible to do so by just modifying the tool itself and no changes are required for the XML documents which are describing the application pages.  For such kind of extension, we need to change the generic program files of the tool to ASP and also modify the XSL transformation so that it generates ASP code out of the XML definitions.  The only changes that may be needed in the XML documents are the <code> sections.  In <code> sections the developer uses a programming language (compatible with the runtime environment of the tool) to define computed attributes or onload and onsubmit functions.  The language attribute in the <code> tag has been devised exactly for providing this forward compatibility.  Since there is even no dependency to the web platform in the XML definitions, it is also possible to use them for generating desktop applications.

Automatic formatting of the page layout, title and icon makes it easy to develop visually appealing pages with little effort.  Another feature is automatic logging of user requests and important queries in a log file.  Also all strings used in the generic scripts are defined in an external resource file, making it easy to translate the tool into other languages.

Extensibility Mechanisms

It is not possible to assume that a tool, no matter how much complicated and thorough, can address all the needs of its users.  By defining computed fields or the onload and onsubmit function the developers can address the specific processing needs for the pages, and at the same time take the most out of the generic capabilities offered by tool.  Moreover, XPage is free and open-source software.  So the developers can also add new features to the whole system by appropriately modifying the generic program files and the XSL transformation.

In the insert, edit and delete pages, it is possible to define two <code> sections named onload and onsubmit.  The developer can use programming language in these functions to extend the basic functionality of the pages.  The onload function is called prior to displaying the page and the onsubmit function is called in the final step prior to completing the execution of page (e.g. before inserting the rows in the database for insert pages.)  If each of these functions returns a non-zero value, the execution of the page is aborted; all outstanding transactions are rolled back and the return value of the function is shown to the user as an error message.

In onload function the developer may perform additional checks for validating the page operation.  For example in a delete page, the developer may cancel the deletion request if some attribute has some special value.  In this case the view page that is responsible for displaying the information before removal displays the error message returned from the onload function instead of the delete confirmation button and informs the user that deletion is impossible.  The onload function may also be used to initialize some of the data entry fields in the forms.

In onsubmit function the developer may perform additional checks on the data that the user has provided in the forms.  It is also possible to use this function for executing complementary database queries.  For example, in the contactdelete page developed in the preceding section, instead of aborting the deletion process when related rows exist in the calltrack table, we could have written an onsubmit code to delete every such rows upon confirmation of the user.  The same capabilities exist in edit and insert pages.  It is also possible to use the onsubmit function to write completely customized operations in insert and delete pages.  The developer may specify noinsert and nodelete in the definition of the pages and then use the onsubmit function to perform all the required operations manually.

Support for Different Database Management Systems

Thanks to the PEAR DB class, XPage supports a variety of relational database management systems.  Configuring the tool to use any of these database systems is done by substituting a single line in the configuration file of the tool (inc/config.php).  In all generic program files, the database operations are executed by using the methods of this class.  The interface that this class provides is very simple and the developers may easily use it in their custom onsubmit and onload functions to execute additional database queries.  The tool currently supports the following database management systems:

1. PostgreSQL

2. MySQL

3. InterBase

4. Mini SQL

5. Microsoft SQL Server

6. Oracle 7/8/8i/9i

7. ODBC

8. SyBase

9. Informix

10. FrontBase

Support for Relationships

In the view, insert and delete pages the developer can simultaneously work with two data sources.  This feature can usually be employed in designing pages that deal with parent-child or master-slave data stored in two tables having a one-to-many relationship.  Theoretically it is possible to design application without using this feature; however this capability results in producing systems that are more close to the view and expectations of the end users.

Queries Instead of Tables

The process of data retrieval is totally based on queries rather than on the tables.  Simplicity of the address book application does not reveal the importance of this feature, however in large systems, using the queries allows the developer to maintain a high-level view of the application data when defining the pages.  Moreover the queries are stored in external documents and can be reused across the pages.

Consistency in Definition of Page Types

The definition syntax is very similar for different page types and despite their different functionalities, similar tags are used to define similar constituents of the pages.  For example in all page types the <field> tag is used to define an information item; it is used for displaying an attribute in view pages, for defining a criterion in search pages and for defining a user input element in insert pages.  The same is true for the <primarykey> and <pageparam> tags.  It has been tried to make the language of the tool easy to learn and remember.  The consistency in the definition language makes it simpler to develop high-level GUIs for visually designing the pages.