ID Generation can provide identifiers for fields in forms.
Form Generation System | Model Reader System | Configuration Reader | ID Generator Services Factory
Each section is structured to address purpose, description, design considerations, scope of effect, and relevant code packages.
This service generates a unique key value for a form text field. Whereas ontology services help provide values that carry semantic significance, ID generator services simply provide keys to uniquely identify a record with respect to other records in the same document or perhaps even records within other documents.
For example, they could be used to uniquely tag samples in an experiment. Implementations of the ID Generator Service interface could provide a key that did not already appear in a database or records.
Purpose | To generate UIs for Project35 which suit displays on desktop and Tablet PCs. |
---|---|
Description |
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.
Project35Menu contains general-purpose code for handling plugins;
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
radio fields. 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. |
Design Considerations | 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
project35.desktopDeployment and project35.tabletDeployment packages. |
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 project35.mda package . |
Design Considerations | We wanted a system that was capable of supporitg a replacement of the Schema Reader and it tends to communicate with the Schema Reader via an interface. This system doesn't depend upon a specific implementation of the Schema Reader. 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 |
project35.mda.schema , project35.mda.config , project35.mda.model (for more information on the last, see sections on Native Data Structures and Record Model Factory.
|
Purpose | To provide an identifier that can be used to populate an identifier field. |
---|---|
Description |
The ID Generator Service interface extends
ID Generator Service Interface
|
Design Considerations | Many of the use cases in bioinformatics use identifiers to uniquely label experiment records. For example, if a data set describes a number of samples, they would each get a unique identifier so they could be processed better by analysis programs. Unlike ontology services, identifiers don’t have a semantic value. However, identifiers may have naming conventions which use domain-specific phrasing. For example, a unique identifier for a sample might include the name of the laboratory where the work was done. Project35 needed some kind of service which could generate unique keys. This was the incentive for developing the IDGeneratorService interface.
|
Scope of Effect | ID Generator services are only ever used for attribute fields. |
Relevant Code Packages | IDGeneratorService is defined in the package project35.soa.id . It will appear in project35.desktopDeployment.IDFieldView . The class name for an IDGeneratorService will be stored in project35.mda.config.AttributeFieldConfiguration .
|