Validation can be performed at the level of a whole document, the current record, or a field within the current record.
Form Generation System | Model Reader System | Configuration Reader | Validation Services Factory
Each section is structured to address purpose, description, design considerations, scope of effect, and relevant code packages.
There are three types of validation services that check the correctness of record data. Field level validation services validate the content of a particular field. For example, they could check that the value is a legal float number or that it matches a particular regular expression pattern. These services would be triggered whenever the user tried to commit changes to the current record.
Record level validation services detect incorrect combinations of field values within a given record. For example, suppose a form had fields for "gender" and "cancer_type". A record level validation service could be developed to detect an error for a "male" who had "cervical cancer". Like field level services, these services would also be triggered when the user tried to commit changes to the current record.
Document level validation services detect data entry errors in the entire document. These services could identify patterns in one record that donít fit given the patterns of values found in another kind of record. For example, a document describing an experiment could have records describing a lab protocol that were inappropriate given the kind of sample described in another record.
Document level validation services would be triggered either when users explicitly wanted to view errors in the current document or when they attempted to export it to some final submission format. In the latter case, the presence of errors would prevent users from sending final draft documents to data repositories. This feature would help ensure that submissions had a high level of data quality.
|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 the 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 provide field level, record level, and document level validation services.|
Project35 supports validation services which can effect a field, record, or document. The Validation Services Factory is responsible for producing an instance of what is described here. Field and record validation services are triggered whenever the end-user attempts to commit changes to the current record. The exceptions are field level validation activities that check whether a required edit field has a value or if a required list field has one child record.
In the Project35 tool, document-level validation services are only triggered when end-users try to export a data set to a final submission format or when they use the "Show Errors" feature in the View menu.
Field level validation services are intended to identify problems in the value of an edit field or with the composition of child records found in a list field. Record-level validation services are intended to identify field values which are legitimate when considered in isolation but are wrong when considered in combination with other field values. For example, a form could have fields such as "cancert_type=ovarian" and "gender=male" which form an illegal combination of values. Document level validation services are intended to identify errors that appear in disparate parts of the same data set.
The main validation utility used in Project35 is
Inheritance Hierarchy of Validation Service Classes
The top level class is
The code base needs to be corrected so that all three of document, record and field level validation services subclass from
Most of the classes in
Inheritance Hierarchy of Default Edit Field Validation Services
Many of the validation classes implement a
In order to minimise the number of times validation services are instantiated, the
Validation facilities in Project35 are extended by the Alerts System. To allow validation services and alerts to work together, the "validate" method for all validation services returns a collection of Alert objects which could represent errors or warnings.
Originally, all the validation services dealt with errors in edit fields. As the project progressed, the interfaces for various services became more complicated. For Project35, all the service classes were overhauled so that services had a more consistent API. One of the most important changes was allowing service classes access to a wide number of application objects that might help guide their activities. More of this is covered in the discussion on Contexts in the Architecture Overview section.
|Scope of Effect||The current schema reader associates most type checking services with record fields.
Record and field validation services are activated in the following
Document level validation services are triggered when users try to use the "Export to Final Submission Format" button in the File menu or when they try to use the "Show Errors" button in the View menu. Code that calls validation services can be found in the
|Relevant Code Packages||Most classes related to validation are defined in the
Back to top