Project35 renders forms based on an XML schema which defines the records and fields that can appear in an XML data set. Users use the forms to produce XML files which can validate against the XML schema. This documentation is organised into two main sections: general and detailed. The application uses a Configuration Tool to allow application designers to associate various properties and services with concepts defined in the schema. The generated forms support the generic features of the data entry tool. However, projects may have to invest in making plugins/services to enhance the functionality of their forms.
Currently the application supports deployments suitable for regular PC screens and for Tablet PCs. Project35 can be deployed as both a standalone application and as a component called from another client application. The overall architecture is illustrated below.
The process begins when the Model Reader System interprets a data model. The Schema Reader reads an XML Schema which describes the records and fields that can appear in a document. Although XML Schema is a very expressive language, there are some application features that it cannot express. Project35 compensates for this by having a Configuration File which maps schema concepts to various application properties and services. The Configuration Reader is responsible for understanding this file.
Information provided by the Schema Reader and the Configuration Reader are combined to create templates of Native Data Structures which represent form records. These templates are managed by Record Model Factory and are instantiated whenever Project35 needs to create new record objects to hold data.
The IO System manages how Project35 stores and retrieves its data sets. Project35 serialises its data as XML files which validate against the XML Schema. By default, documents are saved as *.PDZ files. This native file format is a ZIP file containing multiple layers of information. The application can also import or export the form data as an XML file. This format is used to produce versions of the document that are submitted to data repositories. When Project35 reads a document, its I/O routines use the Record Model Factory to create a tree of data objects. This tree is then passed to the Form Generation System.
Project35 can generate applications that suit desktop and TabletPC display devices. The form generators use properties of the data objects to render basic forms and use information held by the Configuration Reader to render other aspects of the application.
The generic aspects of form generation and IO alone would not be sufficient to service some use cases. To support domain-specific functionality, the architecture supports different kinds of service interfaces that can be implemented by developers. Service families supported by the application include:
The Ontology Service Framework is a system that generates ontology services, which can be used to help mark-up form fields using terms from an ontology. Validation services are used to validate a whole document, the current record or a field within the current record. Plugins can be developed which apply to an entire document, the currently edited record or the currently edited field. ID Generator Services generate unique identifiers that can be inserted into form fields. Generally, this feature is used to generate keys for ID attributes defined in XML tags.
The application also supports alerts, which is a passive way for domain experts to share their knowledge of data entry patterns with novice users. Using the Project35 Alerts Editor, a domain expert creates an alert, which is a set of search criteria that is associated an intent. The list of currently supported intents include:
The domain expert uses the Alerts Editor to produce Alerts bundles, which are collections of Alerts whose descriptions are stored in ZIP files. Novice users can import alert bundles and use the patterns to supplement normal validation checks. In the generated applications, the Alerts System produces Alerts that are then applied whenever document error checking is triggered. The Alert System describes this topic in depth.
Project35 has a Meta Data System which is used to record meta data about the document in a *.META file. This file is embedded within each native *.PDZ file. The Meta Data System makes a record of the ontology terms that are used to mark-up form fields. The system then serialises this and other meta data information using the IO System.
The software is intended to support two phases of development: rapid prototyping and production line development. Project35 is designed to produce generated applications that can support daily data entry tasks. However, projects may elect to use the software simply as a means of gathering end-user requirements about what features a data entry tool should support. Project35's support for rapid configuration changes makes it well suited for gathering suggestions from end-users, project leaders and developers alike. The suggestions can be used to generate a protype of a proposed system. The Configuration Tool also has a feature which can present configuration options in a human-readable functional specification. The Configuration System and the Record Model Factory are used together to produce this document.
The remainder of this overview is dedicated to explaining aspects of services used in Project35, and the methods by which they access information about the application.
Project35 services adopt a published abstract interface in order to hide implementation details from the rest of the system. They are characterised by a task, a scope of effect and an aspect of persistence. Each of these properties affects the way the service behaves in the application.
The task describes what the service does. It is expressed to end-users through a name that would be displayed in a menu or list item, and a description that could be displayed to show more information about the service.
The scope of effect determines whether a service is meant to affect the current form field, the current form and all of its subforms, or the current document. Document-level services are advertised as menu items in the menu bar of a dialog window. Record-level services are advertised with buttons that appear at the top of a form. Field-level services are indicated through buttons that appear at the end of a form field.
Services are considered persistent if one service instance is used for all requests and transient if a new service is instantiated for each request. Transient services would tend to be those which are simple and use little computational resources. Instantiating a new service object for each request has the benefit of reducing undesirable side effects of other program variables. Persistent services tend to be services which either use significant computational resources or which are meant to exhibit a "memory" of user activities throughout a user session. For example, if a service needed to start up a database, then it is better if the system assumes it is persistent to reduce the startup overhead associated with multiple requests.
Project35 supports specialised and generalised services. The differences between the two are in what aspects of the forms are enhanced, the means by which those enhancments are activated, and the nature of the interfaces used. The following sections describe the kinds of services that are supported by the architecture.
General services are intended to support all non-specialised kinds of tasks that are required to customise the generic aspects of form generation. 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. General services implement a general plugin interface. More information can be found on the architecutre page for Plugins.
Specialised services address issues such as the generation of unique key identifiers, the mark up of form fields with controlled vocabulary terms and the validation of form data. Whereas general services are always triggered through an explicit action from end-users, some specialised services may also be triggered as part of programmatic activities. Specialised services use abstract interfaces that are associated with specific kinds of data entry tasks that were originally identified as being common to a number of bioinformatics applications. The following are types of services that are supported and more information can be found on their respective architecture pages: Validation, Ontologies, and ID Generation.
Services can manipulate the host application in a number of ways. They can access three collections of variables known hereafter as contexts.
The variables maintained by these contexts allow service designers to customise the UI components and the three kinds of scope limit undesirable side effects. For example, designers could use form context to help highlight the currently selected field in blue. However, in using the form context, the change in colouring would not affect the same field as it may appear in other open documents.
| Purpose | To provide an extensible means for services to use parameters values that come from the Project35 application or from other software applications. |
|---|---|
| Description |
Project35 manages a number of global variables through the use of three classes: Class Relationship Diagram for Project35 Context Classes
The RecordModelFactory recordModelFactory =(RecordModelFactory)Project35FormContext.getProperty(Project35FormContext.RECORD_MODEL_FACTORY);
Other objects have a scope limited to a single dialog. NavigationTree navigationTree = (NavigationTree) Project35DocumentContext.getProperty(Project35DocumentContext.NAVIGATION_TREE);
|
| Design Considerations | The development of Project35 Contexts was in response to the effect that ad-hoc development requests had on the collection of services that were supported by the tool. In some cases, a service needed to have access to another part of the application or some additional value. Delivering an extra parameter value to the service often required that the value was passed along through a delegation chain of objects that had nothing to do with the service operation. This caused parameter bloating in the methods of many classes, especially GUI-based classes.
Moreover, because different services had slightly different parameters, it wasn't possible to take advantage of common code properties. The more similar services are to one another, the easier it is to write code which can service all of them. All of the Project35 services needed an extensible way to use new kinds of information that could be supplied by objects in the Project35 application or those produced in other systems. Hence, all services were reworked so that they expected context objects. In future, Project35 will support key values for objects that come from third party software products. Data modellers will be able to add more properties using the Project35 Configuration Tool. |
| Scope of Effect | In the Project35 code base, the context classes are used prolifically:
|
| Relevant Code Packages | Project35's context classes are defined in the project35.system package.
|
