Как осуществить установку и удаление модуля с помощью Zend Framework - PullRequest
4 голосов
/ 16 января 2011

У меня есть веб-приложение, построенное с использованием Zend Framework, которое содержит много модулей.Все эти модули являются «необязательными» и используются для обеспечения расширенной функциональности.Некоторые из этих модулей пишут свои собственные журналы и т. Д. Я думал о том, как выполнить установку и удаление behvaiour для этих модулей.

Сначала я хотел предоставить каждому модулю InstallationController, UninstallController и т. Д.и пусть они справятся с установкой.Но затем я начал думать о подходе, который включал бы включение каждого модуля в install.ini, uninstall.ini и т. Д. Затем ядро ​​обладает функциональностью, позволяющей сократить и действовать в соответствии с ними.Примером uninstall.ini для файла модуля foo может быть

[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

Тогда пользователю будет предложено указать опции Complete или Save Logs при запуске удаления foo модуль.Один из плюсов, которые я вижу в этом подходе, - это общая базовая механика, которая обрабатывает все операции, и тот факт, что никакой код на самом деле часть модуля foo не будет работать во время удаления.

У меня никогда не былораньше делали этот тип поддержки установки / удаления / обновления в веб-приложении, поэтому любые идеи и советы были бы хорошими.

Ответы [ 2 ]

4 голосов
/ 20 января 2011

Я очень быстро разработал некоторые начальные мысли перед утренней встречей здесь на работе.Как вы думаете?Должен ли этот подход быть рассмотрен и исследован больше?Это некоторый формат обсуждения псевдокода здесь, и он никоим образом не является полным набором функций и классов, но я думаю, что основные идентификаторы достаточно ясны.

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
{
}
3 голосов
/ 16 января 2011

Я тоже буду сталкиваться с этой проблемой, поэтому мы, вероятно, сможем помочь друг другу. Я просто добавлю некоторые мои мысли к тому, что вы уже изложили.

Я думаю, что установка / удаление контроллера будет излишним, соответственно. слишком много избыточного кода.

А как насчет основного модуля установщика, который обрабатывает все операции установки и удаления программного обеспечения. Затем этот модуль будет искать файлы install.ini и удалить файлы ini и соответственно выполнять необходимые действия. Модуль также будет выполнять операции по умолчанию, если директивы в файле install.ini отсутствуют. Таким образом, вы можете убедиться, что вам нужно только добавить нестандартное поведение в INI-файлы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...