General

Download

Overview
Project History
People

Use Cases Scenarios
Use Case Requirements
Bugs and Known Limitations
LHA

User Manuals Getting Started
General Tour
Configuration Options
Logging Tool Tour
Administration Tool Tour

Developers Architecture
Analysis of Design
Creating Plugins
Future Enhancements

Component and Standalone Modes

CST is designed so that the the logging and administration tools can be deployed either as standalone applications or components spawned by other applications. The main display classes for the tools are LoggingToolDialog and AdministrationToolDialog. Objects of these classes are initialised with an instance of SessionProperties, which is a HashMap of various application properties. SessionProperties maintains references to parts of the application including instances of logging and administration services. The services are in turn initialised with descriptions of activities, activity steps and database properties.

The main difference between component and standalone application deployments lies in how configuration data are acquired. LoggingToolApplication and AdministrationToolApplication, the classes which launch standalone applications, parse command-line arguments and pass configuration data to the logging and administration dialogs.

In the component mode of deployment, the client application is responsible for initialising the SessionProperties object used by the dialogs. DemonstrationLauncherEditor contains an example of code which initialises and launches each tool in demonstration mode.

CST has been designed to minimise its use of static variables which would cause undesirable side effects if several components were launched in the same virtual machine. If CST were only created to be launched as a standalone application, then it would be convenient to manage the application's TrialSubjectModelFactory using a Singleton pattern such as:

	public class TrialSubjectModelFactory {

		private TrialSubjectModelFactory() {
			...
		}

		public static getTrialSubjectModelFactory() {
			if (trialSubjectModelFactory != null) {
				trialSubjectModelFactory = new TrialSubjectModelFactory();
				...
				...
			}	
			return trialSubjectModelFactory;
		}
	}

However, a client application could launch two instances of the Logging Tool, each managing data for different activities. If the single TrialSubjectModelFactory instance were used, it would be possible that the single instance of TrialSubjectModelFactory would contain descriptions from both sets of activities. Instead of using statically maintained global variables, CST makes use of the SessionProperties hash map to store all the information needed by either an instance of the Logging Tool or an instance of the Administration Tool. The idea is borrowed from a common feature used in web applications to establish the scope of session variables.

CST does make use of static methods. For example, the software uses the following method to validate all instances of TrialActivityModel:

TrialActivityModel.validate(TrialActivityModel trialActivityModel))

The method does not manage any static data and the activity record to be validated contains enough information for the class to perform all the validation checks it needs.

Instances of SessionProperties maintain a boolean property called IS_COMPONENT_MODE. The value is used in different parts of the code base to ensure that the tools behave appropriately in each of component and standalone application modes. For example, consider how the following code fragment in DatabaseMenu is used to close the Logging Tool in each mode:

	private void exit() {		
		...
		...					
		
		Boolean isComponentMode
			= (Boolean) sessionProperties.getProperty(SessionProperties.IS_COMPONENT_MODE);
		if (isComponentMode.booleanValue() == true) {
			parentContainer.setVisible(false);
		}
		else {
			System.exit(0);				
		}		
	}

If a tool operating in component mode were closed by invoking a System.exit(0) call, the tool as well as the client application which invoked it would be shut down. The use of the mode variable allows the tool to adjust its behaviour to suit the circumstances in which it is invoked.

Author: Kevin Garwood


(c)2010 Medical Research Council. Licensed under Apache 2.0.