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:
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:
project35.mda.schema.SchemaReaderInterface
interface;
RecordModel
objects (see project35.mda.model
package);
RecordModel
objects as templates in the RecordModelFactory
object. These templates are used to instantiate records created in the program;
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
:
RecordModel
EditFieldModel
ListFieldModel
IDFieldModel
GroupFieldModel
DataFieldModel
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.
project35FormContext
variable. You may have to add this change to classes such as project35.desktopDeployment.Project35Application
and others that have a main method;
project35.io.NativeFileReader
and project35.io.NativeFileWriter
;
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:
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:
desktopDeployment.EditFieldView
and implements desktopDeployment.CustomisedFieldView
(eg: tabletDeployment.TabletTextFieldView
);
desktopDeployment.RecordViewFactory
class to associate
some field view type with the class you've written. (see the
constructor for tabletProject35.DataEntryPanel
).
The advent of the Project35 Configuration Tool has made it easy to extend the system's capabilities of recognising new configuration attributes.
models/project35_form_configuration/model/project35_form_configuration.xsd
;
project35.mda.config.Project35ConfigurationReader
so that the parser can detect XML tags of the new attribute;
project35.mda.config
;
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.
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.
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.