Provides classes for generating a set of JavaServer Pages from a XSD schema stored in a Tamino database. The generation process is divided into five steps represented by the five classes:

Generate

Generate provides the command line interface for calling the X-Application Generator. It first calls the method prepare of class Prepare and afterwards it calls the method generate of class Generator.

Prepare

Prepare copies all necessary resources from [~xapplication]/templates to the target directory of the application to generate, by calling the method copy of class WebInf. Afterwards it creates the config.xml file in the target directory and then calls the create method of class WebInf.

WebInf

WebInf provides a copy method which copies all files of a directory recursively to a target directory. It is used by method create which creates the web.xml file (by calling the method createWebXml(...)) and copies the necessary jar files to the application target directory.

Generator

The method generate generates all JavaServer Pages (search, list, create, view, modify, and delete), therefore the underlying schema is loaded into an internal tree representation and then processed in two different ways. Firstly breadth first search is used to find candidate fields to be used as columns in the browse page (list.jsp) table and secondly depth first search is used to find a display structure for the database fields in all the other JavaServer Pages.

In order to generate the resulting structure_[root element name].xml file, a tree representation is build inside the memory first. In memory means that it is gradually build up as a JDOM tree and at the end exported to a XML file. The following schema shows how the generation process is organized.

The method breadthFirstSearch(...) builds a class that implements the interface BreadthFirstInstructionHandler, which can be seen as the connector between the Generator class and the BreadthFirstSearchProcessor class. Afterwards the process(...) method in BreadthFirstSearchProcessor is called, which traverses the schema tree in the way described below.

Depth-first-search follows the same structure, but with a different strategy which is described below as well.

The method process(...) in BreadthFirstSearchProcessor scans the XSD tree level by level and uses the order in which leaf nodes are discovered as the order in which those elements appear in the structure file and consequently appear in the resulting table of the browse page. Each time a simple field is found the method processField(...) in the BreadthFirstSearchInstructionHandler is called which creates an element in the browse subtree of the in memory representation of the structure file. This strategy is visualized in the following picture.

Note: If complex elements contain attributes which are -by definition- simply structured, those attributes are processed first, so that they can appear well before the actual complex parent.

The method depthFirstSerach(..) uses the path to leaf nodes as heading under which the corresponding elements are displayed (see picture below). Depending on the type of the node the different methods in DepthFirstSearchIntructionHandler are called, which again create the different entries in all subtrees of the in memory representation of the structure tree, but the browse part (which is handled by breadth first search).

All the other methods of class Generator are for helping and supporting the methods described above.

XslParser

The XslParser class provides the method parse which calls a XSLT processor for every stylesheet specified in a <page> tag in config.xml.

Classes constituting the GUI interface

GuiServlet

The Generator GUI consists of a servlet which is implemented in this class together with a pair of HTML pages. The architecture and the associated files are described below.

The two layouts of the GUI are coded in two HTML pages which are called Gui.html and GuiRemote.html. They consist of 'normal' HTML tags and special place holders with the prefix xapp_. During the parsing of those pages (1.) in the method fillLayout(...), the placeholders are used to trigger method calls (2.) which fill these spaces with dynamic information.

After an application is generated a new instance of the class ServerThread is created (3.), which encapsulates the shutdown and start of the Tomcat servlet container. This is necessary to be able to access the newly created application, because Tomcat currently does not recognize new web applications at runtime.

ApplicationLauncher

The class ApplicationLauncher represents a GUI as well, it's the GUI that shows up when the 'Software AG Tamino X-Application Start' feature is invoked from the Tamino X-Plorer. Like in GuiServlet a HTML template is parsed (startApp.html) and the place holders are replaced by dynamic information. The most important method here is getStartDirs() which scans the webapps directory of the local Tomcat installation for generated applications. Therefore it is checked if a directory contains a config.xml file with the same value in the doctype tag and a WEB-INF/web.xml file having the same values in the context parameters TAMINO_URL and TAMINO_COLLECTION as the doctype that is currently selected.

ServerThread

ServerThread represents the thread in which the Tomcat servlet container is running which is in charge of accessing newly created web applications. This is necessary because Tomcat does not recognize web applications which are copied into the default webapps directory during runtime.

The helper classes

This section describes all classes not directly involved in the generation process.

ConfigContainer

The class ConfigContainer encapsulates all the configuration information specified in config.xml and web.xml. Therefore those two files are parsed and stored in a JDOM tree representation. Afterwards -by calling the appropriate method- a configuration parameter can be accessed (read only).

GenUtil

The class GenUtil contains helper methods for recognizing nodes in the to be traversed schema tree and methods which facilitate the creation of query paths.

Log

Log is a simple implementation of a logging functionality mainly used for debug purposes. All classes in the generator package hold an instance of this class. Currently it's not possible to enable/disable the debug output without editing the source files and compiling afterwards. The place to change this preferences is in the constructor of each class.