Architecture Extensions

This section describes ways that developers could extend the core code base. There are a number of tasks which the tool does not directly support, but which could be modified to that it does. These include the following topics:

Replacing the schema parser

Project35 communicates with the schema parser via the SchemaReaderInterface, which can be implemented to rely on XML Schema or other data modelling technologies. A few years ago, we tried to make Project35 run off a data model created by a knowledge acquisition system called PCPack. It was able to generate forms for simple models and proved that the application could be insulated from changes in the way models were read.

To adapt Project35 to suit another model interpreter:

  1. Create a Java class that implements the project35.mda.schema.SchemaReaderInterface interface;
  2. Develop code to parse the model file;
  3. Use the model properties extracted from the model to build up definitions of RecordModel objects (see project35.mda.model package);
  4. Register the RecordModel objects as templates in the RecordModelFactory object. These templates are used to instantiate records created in the program;
  5. Change code in the constructor of project35.mda.schema.Startup so that it instantiates a copy of the new schema reader instead of MSVSchemaReader.

The most important part of this activity is to be able to map model concepts to attributes in the following classes found in project35.mda.model:

Back to top

Adding an extra data layer

Project35 currently has two data layers inside each native .PDZ file:

The information layers are described in more detail in the I/O System. In the future, native files may contain additional layers which describe data quality or aspects of provenance. The way the .meta layer was developed provides a good example of how a new layer of information could be supported. For more information on this, please see the Meta Data Architecture.

  1. Develop data container classes which will hold the information you want to maintain;
  2. Create a manager class that manages the data container classes;
  3. Make the manager accessible to other parts of Project35 by registering it as a new variable in the project35FormContext variable. You may have to add this change to classes such as project35.desktopDeployment.Project35Application and others that have a main method;
  4. Use the hash key you created in the previous step to access the variable from within and;
  5. Decide on a file extension to use for the layer, eg: "*.provenance";
  6. Access the manager object and use it to read and a layer file ending with the extension you wanted. The new layer should appear in *.PDZ files.

If you want this layer to be editable by people, then it is good to look to the design of the Meta Data Editor for guidance:

  1. Write an XML schema which describes the information you want to maintain;
  2. Develop plugins which will load and save data for only the information layer you want. You may have to replace the default File menu features "Open", "Save" and "Exit" because these are designed to open and save a *.PDZ file, not a specific information layer within a *.PDZ file.

Back to top

Creating a new field view

TabletProject35 provides an example of how a new field view can be developed. The application uses project35.tabletDeployment.TextFieldView instead of project35.desktopDeployment.TextFieldView when it renders forms. The steps are as follows:

  1. Make a class which extends desktopDeployment.EditFieldView and implements desktopDeployment.CustomisedFieldView (eg: tabletDeployment.TabletTextFieldView);
  2. Use the desktopDeployment.RecordViewFactory class to associate some field view type with the class you've written. (see the constructor for tabletProject35.DataEntryPanel).

Back to top

Adding Form Properties

The advent of the Project35 Configuration Tool has made it easy to extend the system's capabilities of recognising new configuration attributes.

  1. Add new fields to the configuration data model (see the models/project35_form_configuration/model/project35_form_configuration.xsd ;
  2. Adjust project35.mda.config.Project35ConfigurationReader so that the parser can detect XML tags of the new attribute;
  3. You may have to add new set/get routines in any number of the configuration data structures appearing in the package project35.mda.config;
  4. Decide where in the code base you want to access the new configuration attributes. You will access the Project35ConfigurationReader using the code such as:

Project35ConfigurationReader configurationReader = (Project35ConfigurationReader) project35FormContext.getApplicationProperty(Project35ApplicationContext.CONFIGURATION_READER).
EditFieldConfiguration editFieldConfiguration
= (EditFieldConfiguration) configurationReader.getConfigurationRecord(recordClassName, fieldName)
??? = editFieldConfiguration.getX() 

In the code example, the "X" in getX() represents the new configuration attribute you want to use. You are most likely going to use the code snippet in plugins. However, many parts of Project35 have access to the project35FormContext variable so you can affect changes to the core code base as well.

Back to top

Creating a Web-based Version of Project35

Project35 should be extensible enough to support new forms of deployment such as a version that works on the web. The model and view aspects of Project35's design were sufficiently well separated to allow Tablet Project35 to be developed with minimal work. A web application could be developed such that the view aspect relies on JSP, Java Servlets and the Struts Framework.

Back to top

Upgrading to Higher Versions of Java

The original project on which Project35 was based used JDK1.4 libraries. Project35 is released using JDK1.5 classes, but many of its legacy structures still remain. For example, the use of casting from an array has been used prolifically. In future, it should be replaced with the Java templates feature that is supported in versions1.5 or higher of the Java Developer Kit.

Back to top