Shared Modules
You can store project files in several different ways. It is possible to store complete project in a single file or split the project to separate files and keep modules stored together with the rest of your code in appropriate directories. This greatly impacts modeling efficiency because it enables model reusability, makes it easier to use versioning system or to compare only a small part of the model definitions.
Using modules
Module is a general term for a single logical structure called bundle for Doctrine and Symfony, package for Propel and plugin for CakePHP project.
Modules used in Skipper will be exported to the schema file as an appropriate definitions or directory structure based on your framework. Whole module can be stored inside the main project file or as stand alone file.
External modules
To fully understand a concept of sharing modules or engaging versioning systems it is necessary to understand how Skipper stores modules first. By default every new module is stored inside the main project file (file with .ormdesigner2 extension).
It is a good practice to store each module in a separate file. This will help you to achieve modularity and better project structure. Skipper saves external module to a separate file and refers to it from main project file.
You can easily share module between two projects if it was saved in a separate file. This can be done using Attach module feature which allows you to use one module in more projects.
Note: It’s important to modify shared module only in one project at a time. Otherwise changes could be overwritten by another project.
Setting up external module files
Module storage locations are configured through either Module Settings or Save As dialog. Both ways allow to define whether module will be stored inside the project or in separate file.
Save As dialog allows to configure storage for all the module files from one place. In Module Settings you can define storage for a single module together with the rest of its attributes.
Attaching existing modules
Next important step in module sharing is attaching the external module to your project. This can be done through an Import to project - Attach Module wizard where you enter path to the external module you want to attach.
When the wizard is completed the external module will load. Afterwards, you will see the entities of the attached module in your visual model. Be aware that any changes made in this module will affect every other project sharing this module.
Advantages of modularity
In the following section you will see the benefits of storing your modules in separate files. All of mentioned techniques are optional, but recommended for better project organization.
Better project structure
Good practice is to store module files together with the part of the application that uses them. This helps you to keep all related files in one place and to keep app/module/plugin logic together. When any change in directory structure is made module file will still be available with rest of the files.
Better model files comparability
Another reason for splitting the module into separate files is better file comparability. When a large project is stored inside one XML it can be very hard to check which parts of the module have been changed. On the other hand, when each module has its own file, you will recognize changed modules at the first glance.
Sharing modules between projects
As mentioned in the previous paragraphs, only way to share modules between several projects is to make them external. Even if you do not need to share a module right now it is a good idea to make modules external from the beginning. It will be easier to share them in the future.
Easier version management
Better file structure helps maintain project integrity. When you keep the model file in a directory with rest of the module code files it is easier to keep all of the files in the same version state. For example when you commit your changes on such directory all the necessary files are uploaded together, or when you revert changes all of the related code is reverted too.
Another great benefit which results from this is an ability to quickly assemble new project from external modules. Any new project can be set-up from versioned external modules, external plugins and model files. These files can be attached to Skipper to serve as a basis for a new project.
Keeping project files isolated
It is always good idea to share modules through versioning system. However a problem may occur if all projects use the single shared module from the same directory. Changes in versions will influence all projects at once which may endanger the project consistency.
To avoid this, you can easily isolate model files using SVN. If you will keep the project modules in separate directories maintained by SVN, then you can choose when you will update the changes for each project. This way you can prepare existing project for necessary changes or keep all the project files in the consistent state without updating.
