Projects:Modularity/ConfigurationScript
Contents |
Configuration script definition
Script elements
The elements that can be part of a configuration script are a limited set of Database attributes and Database model changes. The data elements that can be part of a configuration script are defined in a Dataset. The model changes that can be part of a configuration script are hardcoded inside Openbravo.
Backwards compatibility
When a script element becomes a non-script element the scripts containing this element will warn the user saying he is importing as clean something dirty but it will be imported anyway.
Script files
The script will consist in a single file with the information about the changes made in the database model and in the database data that is contained in the dataset definition. The data changes will describe the element that is modified, its old value and the new one.
Exportation tool
The exportation tool allows to export any customization as a set of modules and a configuration script. When this tool is executed it gives:
- Modules that compose the current installation. This will be done calling the export module utility. The purpose of not exporting just the script but also the modules is to avoid inconsistent scripts. For example if a customization adds a new window and modifies a table to make use of it, the first modification would be exported as part of a module and the second one in the script. If only the script is exported it would make reference to a table that is not anywhere. In case modules are modified a warning might be raised.
- Configuration script file.
Algorithm
The way the exportation tool works is as follows:
- The name of the script (industry template) to be exported will be requested as parameter, it can be one of the currently installed scripts or a new one.
- The first step will be to call the module export utility to obtain as files the current modules in the installation. This process will export only the modules checked as “in development”.
- The exportation tool will create a database model composed by all the original components (modules and scripts) except the script it's going to export. This is done reading from files.
- It loads the current model in database and compares with the read one.
- It compares both models. Note that as the modules checked as “in development” are already exported in files they will be equal in both models and the differences will appear for the rest of modifications in other modules. These differences will be saved as part of the script.
- Additionally it could compare all the current source files with the current ones and in case any difference between them they would be saved as part of the script.
Dependencies
While the exportation is achieved it can store the list of modules that the script is modifying, these modules will be necessary to apply the script so they should be saved as dependencies for the script. Note that though all they are dependencies there could be other modules that are also dependencies.
Exporting a customization
A common case of use is to export a customization as an industry template. In this case all the new elements that are part of modules should be in the “customization” module which should be checked as “in development”. The result of running the exportation tool would be:
- A new “customization module” with all the new elements.
- A configuration script.