We attended the drupalcon conference at Barcelona and presented the concepts underlying sifbuilder. It was a great event -more than 400 participants-, incredible city and superb organization. We met very competent professionals that are doing great things with whom to keep in contact and collaborate in the future.
The presentation by Nick Blundell from illuminateict about Drool was very interesting and he is publishing the tool. We feel curious to know how it applies the skin command to themes and how it could find out and install the ecommerce module.
During our presentation we got interesting questions. A participant asked if the modules installed were available locally. We prefer to get them from the original source but it is possible to placethem locally and once locally available they do not need to be downloaded. The basic insert node function is provided by the site and it is available to all installation package refers. A module may implement the logic to export/import specific types of nodes and this be used by the installation packages.
A colleague asked if one to many relationships were taken into account in the automatic generation of a module. The module automatically generated based on its data model currently implements the basic hooks, control, view and model functions. It may evolve in the future to include related tables and linked forms. A participant asked if we had any recommendation for the development of a module. Code generation is very important in the measure that it reflects fundamental decisions of the architecture of the code to develop. In the case of drupal, it is important to understand the architecture of the core and then decide the best implementation of the modules. The modules generated at this time do not pretend to be a recommendation of style.
One question enquired if the site generation provided by sifbuilder supports multisites. Multisite sites may share tables in the database or folders the file system. In the first case, one site typically has a default table prefix and lists shared tables with other prefixes. Thus, there is not a relationship between a site and a prefix but between self-contained site components and specific table prefixes. These components are normally predefined. This implies a lost of abstraction in the site specification model and, in this way, it is not supported by sifbuilder.
When multisites share folders, a multisite site is identified by the source script virtual directory and the configuration file associated to that site with a predefined criteria, implemented in site_conf. To implement the sifbuilder logic, it is necessary to identified when a site is installed. However, the sifbulder script does not reveal the identity of the target site. To find out if a site is installed as a multisite site, it is necessary to recognize the database path and prefix in the chain of possible configuration files, from specific to default. This is now the default behaviour in sifbuilder for drupal.
Here follows a summary of our presentation.
- Automatic generation of drupal sites, backup and cloning of drupal sites, and automatic creation of drupal modules
- presented at http://barcelona2007.drupalcon.org/
- http://www.sifbuilder.com/
- sifbuilder at gmail
- Automatic generation of drupal sites
- What is the rational
- Enable the declarative definition and automatic generation of modular web applications.
- Relying on web application cores
- Integrating open modules and themes
- Abstracting collection, installation, update and configuration of layout and functional components
- Supporting the implementation of functional components automating the generation of new modules based on the declarative definition of their data model
- Definition of a site
- A site is defined as a set of building actions (building chain) carried out by installation packages associated to the site components. This definition may be reflected in a XML file (build file or sib) which is a representation of the calls to the underlying sif installation framework.
- if an action refers to a component, it is associated to the most recent release of that component.
- if the component has dependencies, these may be added to the build chain.
- if a building component is already present in the target site, an installation action may be changed to an upgrade.
- Basic components
- A set of installation packages (sips) that expose the behavior and complement the functionalities of individual web site components (core, modules, themes). Installation packages offer the interface to
- Transpose. Download and explode the site component from the source if not locally available.
- Transfer. Copy the package files from the packages repository to the site codebase.
- Config. Configure the site. Done only by the core installation package.
- Install or Upgrade the component. Installation is dependent on the type of component: core, moduel, theme.
- Conform, including configuration of panels and blocks, setting of system variables and permission and creation of content.
- A set of XML files (sibs) listing actions that represent web site building blocks or define operational web site configurations and profiles
- Sample site creation:
- > php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnethost=localhost --sifnetsite=sbd501_at_localhost drupal5_core_drupal --dev -x -v
> php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnethost=localhost --sifnetsite=sbd502_at_localhost --siburi=./sibs/sib_drupal5_sif_sif.xml --dev -x -v
- > php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnethost=localhost --sifnetsite=sbd501_at_localhost drupal5_core_drupal --dev -x -v
- Backup, restore and clone sites
- If the system is consistent, it cannot be complete, and the consistency of the axioms cannot be proved within the system. Therefore, a site cannot be restored from within itself.
- Backup, restore, clone
- The sifbuilder backup contains three files:
- file.xml, with the configuration of the backup'ed site (including the reference to the pod)
- file.sql, with the sql dump of the pod database
- file.zip, with the tar file of the pod file system
- The sifbuilder restore recreates the database and file system.
- The sifbulder clone takes into account the configuration of the source and target sites to create the site with the new configuration, including database and site credentials, table prefix, and file system location. When specified, the installation package of the core configures the cloned site.
- Sample backup and clone action:
- >php sifcmd.php backup_pod --sifnetsite=sbd502_at_localhost
- >php sifcmd.php clone_pod --sifnetbcksite=sbd502_at_localhost --sifnetsite=sbd501_at_localhost drupal5_core_drupal -x
- Creation of a new module
- Input
- The XML representation of the relational model of the entities used by the module logic.
- Smarty templates reflecting the module architecture.
- Creation of a site with the module generator module installed:
- >php sifcmd.php b --sifnetsite=sbd501_at_localhost drupal5_mod_sifmoduler -f -x
- Output
- for the module, it generates the .module and .install files. The .module file includes the module hooks and the action router based on the menu hook.
- for each entity, it generates the .controlapi file, which contains the control and view functions including add, edit, delete, list and delete multiple records; and the .dao file, that includes the select, insert, update and delete interface to the entity model.
- Process
- Creation of modules is done by the sifmoduler and sifclasses drupal modules, where the sifclasses module exposes the sif and smarty classes and the sifmoduler module creates the module files from the module templates and the module definition.
- The generative spirit of sifmoduler is transmitted to the generated modules and it is possible for the admin to create other drupal modules from any module created in that way.
- Vision
- The vision of sifbuider is that of an XML file containing the actions on core, modules and themes that define a web site. That XML file is referenced by a URI and running that URI builds the site.