Zend framework 如何使用Zend Framework实现模块安装和卸载

我有一个使用Zend框架构建的Web应用程序，它包含很多模块。这些模块都是“可选”的，用于使扩展功能可用。其中一些模块编写自己的日志等。我正在考虑如何实现这些模块的安装和卸载

起初，我的想法是让每个模块都有一个

InstallationController

，

UninstallController

等，并让它们处理安装。但后来我开始考虑一种方法，让每个模块都包含

install.ini

，

uninstall.ini

等。然后核心就具备了对这些模块进行裁剪和操作的功能。模块

foo

文件的

uninstall.ini

示例如下

[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

然后，在运行

foo

模块卸载时，用户将看到

Complete

或

Save Logs

选项。我可以看到这种方法的一个好处是一个通用的核心机制，它处理所有的操作，而且在卸载过程中，

foo

模块中实际上没有任何代码在运行

---

我以前从未在Web应用程序上进行过这种类型的安装/卸载/更新支持，因此任何想法和提示都很好。

我也将面临这一挑战，因此我们可能可以互相帮助。我只是想把我的一些想法添加到你已经开始概述的内容中

我认为有一个安装/卸载控制器将是过分的。太多的冗余代码

---

安装程序核心模块如何处理软件的所有安装和卸载操作。然后，此模块将查找install.ini和uninstall ini文件，并相应地执行必要的操作。如果install.ini中的指令丢失，该模块还将执行默认操作。通过这种方式，您可以确保只需将非默认行为放入ini文件。

在上午的工作会议之前，我很快制定了一些初步想法。你怎么认为？是否应该更多地考虑和调查这种方法？ 这里是一些伪代码讨论格式，它绝不是完整的函数和类集合，但我认为主要IDE已经足够清晰了

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

---

我喜欢这个问题，因为它解决了一个我也将很快面临的问题。很明显，我可以腾出一些代表。因此，如果这还没有得到足够好的答案，我很乐意赞助一笔赏金。你可能会发现以下建议很有趣：是的，我的想法完全正确。在

核心

中使用该功能感觉更干净。此外，如果使用配置方法，模块开发人员就可以决定是否要创建ini、xml等样式的配置文件，因为Zend Framework可以处理这种抽象。然后，核心安装/卸载/升级模块“只”需要实现创建数据库表、将数据写入表或现有文件（如主配置文件等）、创建文件夹等机制。核心模块还将负责在出现错误时回滚安装我对您的两个想法都很感兴趣，并且我想支持，我想建议在create中提供所有这些想法作为草稿，为zend framework命名为

可安装模块

，我们可以从wordpress插件架构、命名约定、文件位置、安装程序、i18n等方面借用一些规范，听起来很棒！我很高兴看到你提到wordpress。我从未看过wordpress插件系统的代码，但总的来说，我觉得它是PHP开源世界中最简单、最清晰的插件系统之一。这可以作为一个常规的zend_组件起草吗？所以我们会有zend_模块，zend_模块安装程序，这样每个人都可以实现他们自己的解决方案？是的，就是这样，我们可以创建一个简单的原型，然后根据需要改进它，去做，我可以与YouVows合作，但没有反馈：）。。。一定有人有意见。我应该用这种方法挖一个深洞或一个地洞，还是你认为它能奏效？