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.
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
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.
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.
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
Microsoft SQL Server
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.
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.
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