Structure of Modules and its installation/de-installation

8th June 2011 13:07 by Webmaster (comments: 0)

1. Introduction

Based on the loose coupling in the Business- and the Input/Output Layer, it is possible to register and de-register modules in Open-LIMS easily. This article describes the process of registering and de-registering of modules in Open-LIMS. Based on an Open-LIMS environment without an installed sample-module, it describes the install-process.

 

Notice: It works with Open-LIMS 0.3.9.9-X-dev or above.

 

2. File Structure

First, you need to copy the files into specific folders.

Folder

Description

/core/includes/[modulename]

Contains the business-logic of a module (Model).

/core/modules/[modulename]

Contains the Input-Output-Logic (View and Controller).

/languages/[language-code]/html/[modulename]

Contains the HTML-Template Files

Moreover, it could be necessary to copy new CSS-files into the /css folder and new JavaScript-files into the /js folder.


3. Configuration Files

The modules contain different configuration files which controls the automatic register process. Please note, that the Business-Logic and the Input-Output-Logic have different configuration files. The locations of the configuration-files are:

/core/includes/[modulename]/config

/core/modules/[modulename]/config

 

3.1 Include Configuration Files

The Business-logic has 5 kinds of configuration files:

File

Description

class_event_listener.php

Contains the classes which listening on system-wide events (event listeners).

class_path.php

Contains the name and paths of public classes. This file is used by the autoloader to find classes.

db_table_name.php

Contains the names of the Database-Tables as constants.

include_info.php

Main configuration file of business-logic-module. It contains all general data. (This is an obligatory file)

register_execute.php

This file contains a function which will be executed on module registering process and each change to the files.

 

Read Full Article...


Database Differences in upcoming version [UPDATED]

13th May 2011 17:01 by Webmaster (comments: 0)

We have created a document with the changes of the database-tables in the upcoming version (Version 0.3.9.9). It based on our current development version in contrast to version 0.3.9.6-2

Database Differences (Tables Only)

 

Update on 15th August: File updated to the current public version.

Minimise Coupling in Open-LIMS

19th January 2011 15:05 by Webmaster (comments: 0)

Current Situation

At the current status of development, Open-LIMS contains complex and static coupling of classes. Subsystems know each other in all directions (see figure 1).

It is necessary to minimise the coupling of all subsystems. For example, the user-subsystem calls the project-subsystem and the other way round. In fact, this is a problematic situation in case of expandability. A second point is the coupling in the I/O-Logic. A clear example of I/O-Logic coupling is the dependency of Project and Sample. In the current situation, both I/O-Logic modules have access on the model of the other one, which is not in every case problematic. However, there is a better way to solve it.

 

Targets and Changes

Our target is to minimise the coupling of subsystems: to minimise the coupling of classes in the business logic (loose coupling) and the dependencies in the I/O-Logic.

That does not mean that a subsystem does not call a class outside of its own subsystem. That means that the subsystems must be hierarchical ordered. Only a call to a lower subsystem is allowed. For example the subsystem Project knows the subsystem User, but the other way round, User should not know anything about Project (see figure 2). Rather, User sends an event and all listing classes (here Project) will react on it.

To minimise subsystem coupling in data-layer, we will reorganise some subsystems (Data and Item) and establish an event-handler to avoid direct calls in a non-allowed direction (e.g. Project in User). Moreover it must be possible to integrate a new, and to remove an old subsystem easily. For this purpose, we will integrate functions for automatically register and de-register subsystems.

In case of I/O-Logic, its modules must interact with another one via defined interfaces. In general all I/O-Logic modules must be independent from all others. In case of Project and Sample it is not possible to avoid that Sample knows something about Project. But it may only extend the other one. In reality, it places a tab in the other one, if both modules are available.

 Figure 1
 Figure 2