How to implement module installation and removal using Zend Framework

Question

I have a web application built using the Zend Framework that contains many modules. These modules are “optional” and are used to provide enhanced functionality. Some of these modules write their own logs, etc. I was thinking about how to implement installation and uninstallation for these modules.

At first, my idea was for each module to have InstallationController , UninstallController , etc., and these handles handle the installation. But then I started thinking about an approach that would include including each module in install.ini , uninstall.ini , etc. Then the kernel has functionality to get around and act on them. An example of an uninstall.ini file for a foo module might be

 [save_logs] folder.remove.data.foo folder.remove.modules.foo file.remove.configs.foo [complete : save_logs] file.remove.logs.foo db.table.truncate.foo_table1 db.table.truncate.foo_table2 

Then the user will be offered the Complete or Save Logs options when starting the removal of the foo module. One of the factors that I see with this approach is the general main mechanic who processes all the operations and the fact that during the deletion some code of the foo module will not be executed.

I have never done this type of install / uninstall / upgrade support on a web server before, so that any ideas and tips would be nice.

Answer 1

I quickly drew up some initial thoughts before the morning meeting here at work. What do you think? Should this approach be considered and explored more? There is some format for discussing pseudo-codes, and this is by no means a complete set of functions and classes, but I think the basic principles are quite clear.

 class Foo_Installer extends Zend_Module_Installer { // The modules bar and exporter are needed by this module protected $_dependencies = array('modules' => array('bar', 'exporter')); // Maybe this should be expanded to include versions like below. Prehaps even be able to // specify a formula of a version like '>2.3 && !2.4 && !2.6' if 2.5 and 2.6 is not compatible // for some reason or another. protected $_dependencies = array('modules' => array('bar' => '1.0', 'exporter' => '2.3')); // Tell the installer what 'script' to use. Should be able to use sources such as xml, ini, yaml, db etc // The install script should contain sections for install/uninstall and update process protected $_installScript = 'fooInstall.xml'; // Place to look for files for update protected $_repo = 'http://www.foobar.com/repo'; } class Zend_Module_Installer { protected function _checkDependencies() { // Check if modules in $this->_dependencies are already installed } public function install() { $this->_checkDependencies(); // Parses the given source of the install script and returns installSteps $installSteps = $this->_getInstallSteps(); foreach($installSteps as $installStep) { $installStep->perform(); } } public function uninstall() { } public function update() { // Connect to repo and check for a newer version of the module. // I think that prehaps a standard should be that modules are distributed // as zip-archives so only one file needs to be downloaded. On a update server // a file named after a standard 'ie packages' could be present that could be // read to determine what packages and versions of these exist on the server // and if there is a new version avalible to download. // // If so we download, unzip, check dependencies, check if dependencies we don't // already have installet are avalible at the server, download these and itterate // until no more downloads are necessery. Then we start runnin the Update() // functions of the downloaded modules in the correct order. } protected function getInstallSteps() { // parses the installscript and instanciates Zend_Installer_Step objects } } // Base class for steps during installation // This apporach makes it easy to extend the installer to be able to do specific things // in specific enviroments. Prehaps configure a some external hardware or whatever. class Zend_Installer_Step { public function perform(); } // Functions to handle the actual logic of creating and deleting stuff. // Some could be standard and some could be application specific class Zend_Installer_Step_Create_File extends Zend_Installer_Step { } class Zend_Installer_Step_Delete_File extends Zend_Installer_Step { } class Zend_Installer_Step_Create_Folder extends Zend_Installer_Step { } class Zend_Installer_Step_Create_Db extends Zend_Installer_Step { } class Zend_Installer_Step_Create_Db_Table extends Zend_Installer_Step { } class Zend_Installer_Step_Create_Db_StoredProcedure extends Zend_Installer_Step { } 

Answer 2

I will also encounter this problem, so we may be able to help each other. I will just add some of my thoughts to what you have already begun to outline.

I think that installing / uninstallController would be redundant, respectively. too much redundant code.

What about the installer kernel module, which handles all software installation and removal operations. Then this module will look for install.ini files and remove ini and accordingly perform the necessary actions. The module will also work by default if there are no directives in install.ini. That way you can make sure that you only need to put the default behavior in ini files.