Plugins can be added at any level to enhance the functionality of the data entry forms at the field, record, or document level.
Form Generation System | Model Reader System | Configuration Reader | Plugin Factory
Each section is structured to address purpose, description, design considerations, scope of effect, and relevant code packages.
General services implement a general plugin interface that is described in later sections. Typically general services will be used to manipulate the record tree representing the data. However, developers can access variables in the Contexts to affect other parts of the application. General services will always be explicitly activated by users by way of pressing a button or menu item.
|Purpose||To generate UIs for Project35 which suite displays on desktop and Tablet PCs.|
Project35's architecture maintains a rigid separation between the
structures that hold data and structures that present them to an
end-user. The model aspects are represented by the Native Data
Structures, information for which can be found in the Core Architecture section. The view aspects are represented
by the following packages:
General Classes for Generating Desktop Project35 Forms
When end-users invoke the "run_project35" script, it spawns an instance of Project35 Application. The object prompts end-users to load a model and it produces template record definitions that can be used to populate a document.
General Class Relationship Diagram for Generating Desktop Project35 Forms
Classes for Generating Edit Fields in Desktop Project35 Forms
The image below describes a more detailed view of UI classes
that are used to render text fields, identifier fields, combination box fields and
Class Relationship Diagram for Rendering Edit Fields in Desktop Project35
Classes for Generating List Fields in Desktop Project35 Forms
Class Relationship Diagram for Rendering List Fields in Desktop Project35
Classes for Generating Forms in Tablet Project35
Tablet Project35 was designed to support the same data models as those used to run Desktop Project35. However, we envisioned that different forms of deployment would be used at different stages of editing the same document. End-users will tend to use Tablet Project35 to do simple data entry tasks which require them to be at a work site such as a laboratory or a remote field location. They will tend to use Desktop Project35 to support complex data entry tasks and to fill in the rest of the document.
Tablet Project35 was designed with the following principles in mind:
The classes used to generate forms in Tablet Project35 are in the
First, some of the menu items have been removed. For example, the File Menu does not contain an "Export to Final Submission Format" button. This feature was deemed non-essential because it was likely this would be done with the Desktop version.
To reduce the number of pop-up dialogs, some features were altered so they used a stack of screens instead of separate windows. For example, consider the "Window" feature in Desktop Project35. When end-users switch from one file to another, a new window grabs focus. In Tablet Project35, only one file is shown at a time. When end-users change the current file, it changes the file loaded in the current window.
As another example, the
To economise on screen real estate, the NavigationTree was removed. It is accessible via the "Where Am I" button, which pushes a view of the
Finally, the right click mechanism for activating ontology services is replaced by pressing a "Mark-up" button which appears at the end of a text field.
Initially, Project35 tightly coupled data objects with the objects that viewed them. This led to severe performance problems because Java would potentially be managing thousands of UI components, each using a collection of Swing objects. This led to stripping the native data structures of references to UI components. Eventually the production of form field views was centralised in the class
The most significant change in the form generation classes came when
Tablet Project35 was developed. Initially we wanted to run the software on a PDA. However, these devices often require a specialised form of the JVM which does not support Swing components. Although the native data structures were stripped of references to UI components, they still had one crucial reference to the swing libraries: the
It became clear that we had to make some changes to the forms. The
The development of
|Scope of Effect||The UI classes are probably not used by anything other than classes in Desktop and Tablet deployment packages.|
|Relevant Code Packages||The classes used to generate user interfaces in Project35 are in the
Back to top
|Purpose||To coordinate the reading of the XML Schema and the Configuration File.|
|Description||This system is a construct for classification of coding areas that are found within the
|Design Considerations||We wanted a system that was capable of supporting a replacement of the Schema Reader. This can be accomplished by having the rest of the system interact with an abstract interface rather than a specific implementation something that interprets schemas. We needed a system that could extract information about data structures form the schema and another thing to extract information about form properties that were related to that schema. This system's role as a whole is to obtain enough information/properties to drive form generation.|
|Scope of Effect||Nothing else uses this as it's an abstract concept but parts of it will be used in other places as in the Configuration Reader. The components of the Model Reader System are used to synthesise Native Data Structures that are then used by the rest of the program. Most of the rest of the programme will only use the Configuration Reader.|
|Relevant Code Packages||
Back to top
|Purpose||To manage options for configuring a data entry application that are not expressed in the XML schema.|
Project35 interprets the XML Schema to determine properties of the
data entry application. However, many of the configuration options
can’t be expressed in the XML Schema language, so they are managed in
Data modellers use the Project35 Configuration Tool to produce the file "ConfigurationFile.xml", which describes all the application properties that are associated with XML Schema concepts. When the Project35 application starts, it reads the configuration file and holds the information in instances of data container classes. These classes have properties which are analagous to classes defined in the XML Schema for the Project35 Configuration Tool (See the XML schema for the Configuration Tool in
Various parts of Project35 use the Project35 Configuration Reader to obtain
configuration data that are used to render the application. For
Other Configuration Files
Project35 maintains two other configuration files in the config directory of a model folder: SessionAspects.xml and FileExtensionsToLaunch.xml
The SessionAspects.xml file contains information about the most recently accessed files, and is managed by the class
The FileExtensionsToLaunch.xml file associates file extensions with shell commands used to launch other software applications. The mappings are used when users press the "View" button on a URL Field View. If the file specified in the text field ends with an recognised extension, Project35 will try to launch an application by making a system call.
It remains the only configuration file that end-users still have to configure. Currently, the
In early incarnations of the software, data modellers had to craft the ConfigurationFile.xml file by hand. The file was awkward and time-consuming to maintain, especially when large XML schemas were being used. This led to the idea of using Project35 to edit its own configuration files. The Project35 Configuration Tool was developed using a schema of configuration properties and a collection of plugins which helped data modellers fill in the forms.
The advent of the Project35 Configuration Tool meant that a configuration file could be designed far more rapidly than it could in previous releases. Enshrining configuration options in an XML Schema also meant it was easy to add new properties.
The configuration options for Project35 expanded to include the selective inclusion of menu items and services which could be associated with a field, record or document scope of effect. With new features came data container classes that held the property values in memory.
|Scope of Effect||
The Configuration Reader is referenced in the file menu classes to determine what features should be included. Many of the classes which generate form fields interact with the
|Relevant Code Packages||Code for
Back to top
|Purpose||To allow developers to extend the functionality of the data entry with code modules that perform domain-specific tasks.|
Project35 supports plugins that can have a scope of effect for the
current field, the current record or the current document. To make
plugins, developers must create a Java class which implements
A Java class Implementing the Project35Plugin Interface
Plugin developers can make their plugin classes implement other marker
interfaces such as
Plugins are associated with different parts of the application via the Project35 Configuration Tool. When the data entry tool is running, plugins may appear in different places. Document-level plugins will appear in one or more of the menus in the menu bar. If plugins are associated with a given record type, then a "Plugins..." button will appear flushed top-right in the main form whenever end-users are editing an instance of that kind of record. If plugins are associated with a field, the same button will appear at the end of the form field.
Early versions of the software used a version of the Project35Plugin interface that had a bloated list of method parameters in an execute method. Eventually, the Project35 Contexts were developed, thereby allowing plugins to access a wide range of program objects. More information on Contexts can be found on the Architecture Overview section.
|Scope of Effect||
Plugins are associated with menus, records and fields via the
Project35 Configuration Tool. Providing that plugins implement the
|Relevant Code Packages||The Project35 plugin classes are defined in the
Back to top