Skip to content
This repository was archived by the owner on Jun 7, 2024. It is now read-only.

Architecture

mlist edited this page Jan 7, 2014 · 5 revisions

OLF has a modular structure, in which a back-end plug-in provides the necessary base classes, as well as user, project and security management. Content plug-ins can then add arbitrary classes and view templates, and integrate with other plug-ins. All plug-ins are finally merged in the front-end application, which utilizes the scaffolding mechanism of Grails to dynamically create Ajax-driven views for user interaction.

Modular structure of OLF

The back-end of OLF introduces two base classes called MasterDataObject and DataObject. MasterDataObjects can be extended by classes representing master data that are maintained by system administrators, e.g. wildtype cell lines or vector systems in the GeneTracker module, or freezers and storage locations in the Storage module. More dynamic content is expressed through DataObject classes, which can be created and modified by regular users, e.g. genes or genetically engineered cell lines in the GeneTracker module, or StorageElements, which contain location data for other DataObject instances, in the StorageModule. This hierarchy makes OLF highly generic, but also allows fine-grained interactions between more specialized classes.

Principle class hierarchy found in OLF

How this model is applied to the individual modules in OLF can probably be understood best by looking at the UML diagrams of the domain classes:

Clone this wiki locally