Launching the logging tool
The user double clicks on the file "run_logging_tool.bat" in the release directory. The
main()routine of LoggingToolApplication will run.
StartupOptions will read
a configuration file that is specified by the end-user.
StartupOptionsinitialises an instance of SessionProperties, which holds references to a number of application components that are needed by various parts of the code.
StartupOptionsuses an instance of ConfigurationManager to read the configuration file specified by the end-user.
ConfigurationManagerwill create the instance of TrialSubjectModelFactory which is used to create new instances of subject and activity records.
At the end of
runmethod creates an instance of ProductionLoggingService , which manages a MySQL database.
- An instance of LoggingToolDialog is created and launched; this is the class which manages the main dialog for the Logging Tool.
Launching the demonstration suiteThe demonstration suite is used to create instances of the Administration Tool and Logging Tool which interact with a shared in-memory database. The database simulates aspects of persistence storage, but only lasts for as long as the demonstration suite is running. This section describes in greater detail how the demonstration versions of tools are created.
Users double click on the
"run_demo.bat"file which appears in the release directory. The batch file invokes the
main()method of DemonstrationToolSuite.
- StartupOptions reads the properties file, creates a record factory for making new records ( TrialSubjectModelFactory) and initialises application objects in a SessionProperties object.
run()method sets the flag
SessionProperties.DEMO_MODEto true. This flag lets the tools know whether they should indicate to the users that they are using demonstration versions of the services. In demonstration mode, the dialogs are specially coloured and the title of the tools starts with [DEMO].
run()method sets the flag
SessionProperties.IS_COMPONENT_MODEto true. This will later help instances of the Administration Tool and Logging Tool know they are being deployed as components from the demonstration suite tool, and not from command-line. For example, when users click the "Exit" button of the Database menu in the Logging Tool, the exit will just hide the Logging Tool dialog rather than call
An instance of
created. These two demonstration services will share the same instance of
DemonstrationToolSuitecreates and launches an instance of DemonstrationLauncherEditor, which lets users launch instances of the Administration Tool and Logging Tool.
Importing trial subject data
- The administrator user presses the "Import Subject Attribute Data..." button in the Administration Tool.
- AdministrationToolDialog. listens for the button press, then uses an ImportTrialSubjectDataUsingWizards object to guide the end-user through the process of importing subject records.
Most of the process is described by steps in the
importCoreDatamethod of the wizard class.
- DataSelectionEditor lets the user choose an import file.
- FindFirstLineDialog lets the user identify the first line of input in the tab-delimited text file.
- PreviewSpreadsheetImportEditor lets the user associate columns from the text-file with the identifier and attributes that appear in a TrialSubjectModel.
Thus far, the import file has only been analysed. The previous steps identified the first row of
input and mappings between columns in the text files and properties in
ImportTrialSubjectDataUsingWizardsuses an instance of TrialSubjectDataSpreadsheetParsingEngine to validate and then import subject records into the data repository.
TrialSubjectDataSpreadsheetParsingEngineuses a two-pass approach for importing data. First it reads the entire file and attempts to validate the records. If no errors are generated, the parsing engine reads the file again to import all the records.
During the validation step, the engine makes use of two classes:
TrialSubjectDataHeaderParserchecks for duplicate header values or columns which don't map to a subject attribute. It also checks to make sure that some column has been mapped to the primary key field.
TrialSubjectDataSpreadsheetBodyParserchecks for duplicate subject identifiers.
If no errors are detected, then
importTrialSubjectModels(...)method of the LoggingServiceAPI.
If any error is detected,
ImportTrialSubjectDataUsingWizardsproduces an error report.
Exporting trial subject data
- The administrator user clicks on the "Export Subject Attribute Data" button in the Administration Tool.
listens for the button click and then calls
to carry out the export operation.
TransferTrialSubjectDatais a legacy class which used to manage both import and export duties. However, I eventually encountered some performance problems with the import routines. Most of the classes which appear in
cst.adminTool.ioare a result of reworking the subject data import feature. I reduced the responsibility of
TransferTrialSubjectDataand in future I will probably rename it as
getSubjectAttributeData(...)method of AdminServiceAPI. This method returns a collection of TrialSubjectModel records which have been stripped of TrialActivityModel objects. Each
TrialSubjectModelonly contains a primary key field and subject attribute fields, all of which are instances of TextFieldModel.
TransferTrialSubjectDatacalls a number of routines which serialise the records in a tab-delimited file.
Recording change historyThis walkthrough assumes that the Logging Tool is using a ProductionLoggingService, which manages a MySQL database.
Users adjust some date field value for an activity. A date field is managed by three
JSpinnerobjects which separately manage day, month and year components. Each spinner has the DateFieldView as a change listener. When users adjust a spinner,
DateFieldViewregisters itself as a changed field with SaveChangesMonitor.
When users try to change focus to some other record or try to quit the application,
SaveChangesMonitoris asked if there are any changes that need to be saved by the user.
If the user elects to save changes,
SaveChangesMonitorasks each registered field to provide a TrialActivityChange. These are held while the monitor prompts the TrialActivityView to commit the contents of the form to the data repository. If the operation succeeds, the monitor calls the
updateChangeHistory(...)method of the LoggingServiceAPI.
TrialActivityChangeobjects are serialised in a change history table which has fields for the date, type, author and description of the change made.
Viewing change historyThis walkthrough assumes that the Logging Tool is using a production logging service that manages a MySQL database.
- User presses the "History of changes for current case study..." button in the Options menu of the Logging Tool. Note that 'case study' could be something else such as 'mouse', 'volunteer' or whatever singular subject name is specified in the configuration file.
- OptionsMenu detects the event and asks the NavigationManager object for a reference to the currently displayed TrialActivityModel.
OptionMenuuses the primary identifier key for the current
TrialActivityModelrecord to obtain a list of relevant TrialActivityChanges from the LoggingServiceAPI object.
LoggingServiceAPIis implemented by an instance of ProductionLoggingService. The
getTrialActivityChangesForSubject(...)method makes a delegation call to a method of ProductionLoggingToolQueries with the same name.
ProductionLoggingToolQueriesis the class which applies SQL queries to the database and retrieves results for logging tool operations.
The results returned for the SQL query are packaged into instances of
ProductionLoggingServicereturns the results to
OptionsMenupasses the collection of
TrialActivityChangeto a ShowActivityChangeHistoryDialog object.
ShowActivityChangeHistoryDialoguses a ChangeHistoryReport object to generate an HTML report. The report then appears in the dialog display.
Author: Kevin Garwood