|
As stated earlier, this tool has been designed to facilitate development
of data-intensive applications by automating the implementation phase. So
the developer still needs to analyze and design the application s/he wants to
build. In particular the data model and process model of the application
should be determined, preferably using ER and data flow diagrams. Since the tool has a page-oriented
development model, creating a prototype
is extremely helpful as it helps the developer in identifying the required
pages.
As the first step, the developer should derive the necessary tables and views
from the ER diagram and create them in a relational database. Thanks to
the PEAR DB class, the tool supports a variety of database management systems
including PostgreSQL, MySQL, MS SQL Server and Oracle. There is a
configuration file in the install location of the tool which should be updated
to reflect the correct information on the type and location of the database
server, as well as the necessary username and password to connect to it.
The developer should then identify all the required pages for the product application.
The necessary pages and their responsibilities can be determined from the
prototype or directly from the data flow diagram. Every page should be
categorized into one of the available page types of view, insert, edit, search and
delete. Although this classification may seem to be restrictive, the pages
are flexible enough for developing real-world applications.
The last and most important step is describing every required page with an
XML document. The format of the XML document depends on the type of the
page. The difference is due to the different requirements and different
features for each page type. For example in view pages the developer
should specify a database query for extracting the information, while for the
insert pages a target table should be specified for storing the data received
from the end user. All these XML documents should be placed in a specific
folder in the install location of the tool. At this time, the product
application is ready to be used.
It is useful to mention that the tool is always present in the runtime
environment and the developer is actually customizing it to produce the intended
system. Whenever the XML document is changed for one of the pages,
the tool transparently re-applies the transformation and re-generates the associated PHP
script.
Since this tool provides an abstract language for describing the pages, just
knowing the correct syntax for every page type is enough for
creating the product application. However understanding how the tool works
internally can help the developer to maximize his/her productivity in using the
tool. The following
figure shows the context-level DFD of the tool.
Context-level DFD
It is shown that the developer configures the tool by providing the necessary
definitions for the pages and their database queries in a set of XML files.
The database queries are actually part of the page definitions; however since
they are usually used in more than one page, they are stored in external files.
On the other hand, the end user interacts with the product application and does
not need to be aware of the existence of the tool. Level-1 DFD of XPage is
shown in the following figure.
|
