Technical Overview
| << previous | | | Introduction | | | Architecture | | | Input Module | | | Business Rules | | | Renderer | | | next >> |
Introduction
The Jalama code base contains several different software modules, all of which have been architected to make them as generic and loosely-coupled as possible. This philosophy was adopted for the following reasons:
- Schema-agnostic: Jalama can generate user interfaces (UIs) for editing XML documents that conform to arbitrary schema, not just EML. This approach is beneficial even if the software is used only for EML, since the EML schema is not yet fully mature, and currently changes between versions. An attempt has been made, therefore, to keep any necessary EML-specific customization code in the same place, to facilitate changes in the future.
- Incorporating other software: Open source software from other projects
is used for some of the functionality in Jalama - for example, Mozilla
Webclient, as described in section 1. Loose coupling means that such software
can be swapped out for newer versions, or even different software altogether,
with a minimum of disruption to the remainder of the system. Examples of
other open-source software used in Jalama include:
- Castor: If Jalama is passed an XML file as input, but if no corresponding schema file is available, Jalama uses Castor to generate a schema file, which it can then use as the basis for UI generation.
- Drools: The UI generation step uses the Drools business rules engine to make decisions about UI creation
These parts of Jalama will be discussed more fully in the Architecture, Input Module and Business Rules pages . - Pluggable renderers: The "Renderer" is defined as the portion of the Jalama architecture that actually displays the generated UIs and allows the user to interact with the underlying Jalama framework. We adopted a "pluggable" architecture for the renderers, which allows renderers to be changed without affecting the remainder of the software. The release version of the Jalama Client software uses the "HTTP Renderer" (a web application comprising a combination of Java servlets and the Mozilla Firefox browser), but earlier Jalama development involved the creation of the "Webclient Renderer" - a Java application that would also display XUL UIs directly inside a Java Swing component (JPanel), using software from the Mozilla Webclient project. Other renderer possibilities that have been discussed but not yet implemented include: using the XULRunner project, which is a stand-alone environment for running XUL applications, and code-generation of Java Swing (or any other language) user interfaces, based on the XUL files output from the Jalama UI generation step.
- Ease of development & maintenance: generic and loosely-coupled modules are easier to test and maintain, and development on different modules can progress somewhat independently.
As described in How it Works - an Overview, The Jalama Field Data Collection Application provides a way of automatically generating data-collection forms from existing EML data sets, deploying these forms onto handheld devices and allowing the user to collect data in the field, and then importing collected data (potentially from multiple handheld devices) into new EML data sets. The following discussion will concentrate mainly on the UI generation and HTTPRenderer aspects of Jalama, since the other aspects of the Data Collection Application, such as synchronizing data into/out of Morpho are already described in How it Works - an Overview.
If you wish to obtain and build the source code for all or part of Jalama, see the developer documentation for details.
You can also browse an online view of our CVS repository
| << previous | | | Introduction | | | Architecture | | | Input Module | | | Business Rules | | | Renderer | | | next >> |