Working in a module
General structure
The structure of the environment for a module corresponds to the structure of the content management system. All objects of the module are shown on the left-hand side of the structure tree. The menu for selecting the editing environment is above the structure tree. However, switching to a ChangeSet is only used with the transformations. All other changes are not made in the context of the selected ChangeSet.
The starting node is the module which contains the meta information on the current module. Underneath the module, different module areas are administrated. If areas are missing, then they can be added on the module node via the context menu.
A module is divided up into the following areas:
- Module settings
- Configuration
- Schema administration
- Data objects
- Users / groups
- Transformations
- Object structure windows
- Interfaces
- Editor functions
- Components
Furthermore, the settings for the web servers and the LRU slots can be administrated via the context menu of the module node.
Web server settings
All web server settings are listed here which are configured in onion.net. The specific transformations thus can be administrated for each web server.
LRU slots
The system-wide LRU slots are shown in the administration for the LRU slots and can be administrated here.
The module
The meta information for a module is maintained in the starting nodes of a module. This includes the following points:
- Manufacturer, authors
- Logo
- Version
- Features
- Dashboard background pictures
- Project-specific files
- Localization
Version
The structure of the version number is based on the general use of version numbers. The meaning of the individual positions is described on Wikipedia for version numbers.
The creation of the version number can therefore be partly supported in the onion.net Editor.
The major version number is manually maintained by the editor. For this purpose there is the point “Version” in the tab “General” of the module node. The number can be increased or reduced there. If this number is changed, then the minor version number is reset to zero at the same time. The major version number is of no technical significance. It should be changed however if the module is a new implementation or includes fundamental changes.
The minor version number is changed if functional changes are made to the module. Functional changes in a module are changes to the schema or interfaces. Since incompatibilities with other modules can result from these changes, this number must be changed.
The revision number is increased when changes are made to transformations. Changes to transformations can have behavioural effects, but should not cause any incompatibilities with other modules.
The build number is set every time the module is exported. If a module is exported, then this number is increased by one. The module is normally exported in the “develop” mode, meaning the module is editable when imported into other systems. If the module is exported in the “release” mode however, the build number is set to zero. The mode is decided on at the time of exporting. In the dialogue there is a “protect” button, with which the module is put into “release” mode. However, the module remains on “develop” in the source system.
Features
Features are defined for a module in order to define the scope of an installation. The module developer must select at least one feature for all elements of a module, so that the element is also installed or updated for the selected feature.
So that the module developer does not have to select every feature, features can include other features. This means that the elements defined for the included feature are also available for your own feature.
Furthermore, there is the possibility, thanks to the module function “interfaces”, of defining dependencies on other modules for a feature. This means a module can only be installed if the dependencies are already available in the target system or are included in module package to be installed. So that a dependency can be created, the GUID, installed minimum version and installed feature must be indicated. The GUID is the clear identification for a module in the module system and is shown as a tooltip when you hover over the module node with the cursor.
Background pictures
Each module can provide its own background pictures for the Dashboard. The way the background configurator works is described in the point module system.
Project-specific files
Under this tab, DLLs can be integrated into the project, which provide further project-specific functions.
Localization
In the module node itself, language-independent information is maintained. Since however there is also language-dependent information on the module itself, this is listed in the structure object window below the module. In this list there is already at least one language, which, at the time of the creation of the module, was also created as a default language.