How to implement module installation and uninstallation using Zend Framework

I have a webapplication built using Zend Framework that contains a lot of modules. These modules are all "optional" and are used to make extended functionality avalible. Some of these modules write their own logs etc. I was thinking about how to implement installation and uninstallation behvaiour for these modules.

At first my idea was to let every module have a InstallationController, UninstallController etc and have these handle the installation. But then I started thinking about an approach that would involve letting each module contain install.ini, uninstall.ini etc. Then the core has functionality to pare and act upon these. An example of an uninstall.ini for the module foo file could 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 would be presented with the options of Complete or Save Logs while running the uninstallation of the foo module. One of the upsides I can see with this approach is a common core mech开发者_如何学编程anic that handles all the operations and the fact that no code actually part of the foo module would be running during the uninstallation.

I have never done this type of installation/uninstallation/update support on a webapp before so any ideas and tips would be nice.

---

I very quickly drew up some initial thoughts before the morning meeting here at work. What do you think? Should this approach be considered and investigated more? It's some pseudo code discussion format here and it is in no way the complete set of functions and classes, but I think the primary ides is clear enough.

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
{
}

---

I will face this challenge too, so we can probably help each other. I'm just gonna add some of my thoughts to what you've already started outlining.

I think having an install/uninstallController would be overkill resp. too much redundant code.

What about an installer core module which handles all the install and uninstall operations of the software. This module would then look for the install.ini and uninstall ini files and perform the necessary actions accordingly. The module would also do default operation, if the directives in the install.ini are missing. This way you could make sure that you only need to put non-default behaviour into the ini files.