Wie implementieren Modul Installation und Deinstallation mit Zend Framework

Question

Ich habe eine Webapplikation mit Zend Framework gebaut, die eine Menge von Modulen enthält. Diese Module sind alle "optional" und dienen dazu, erweiterte Funktionen verfügbar zu machen. Einige dieser Module schreiben ihre eigenen Protokolle usw. Ich habe darüber nachgedacht, wie man die Installation und Deinstallation für diese Module implementiert.

Zuerst war meine Idee, jedes Modul eine InstallationController, UninstallController usw. zu haben und diese die Installation behandeln lassen. Aber dann fing ich an, über einen Ansatz nachzudenken, der beinhalten würde, dass jedes Modul install.ini, uninstall.ini usw. enthält. Dann hat der Kern die Funktionalität, diese zu zerlegen und darauf zu reagieren. Ein Beispiel für ein uninstall.ini für das Modul foo Datei

könnte

[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 

Dann würde der Benutzer mit den Optionen von Complete oder Save Logs präsentiert werden, während der Deinstallation des foo Modul ausgeführt wird. Einer der Vorteile, die ich mit diesem Ansatz sehen kann, ist eine gemeinsame Kernmechanik, die alle Operationen behandelt, und die Tatsache, dass während der Deinstallation kein Code tatsächlich Teil des Moduls foo ist.

Ich habe noch nie diese Art der Installation/Deinstallation/Update-Unterstützung auf einer Webapp vor so irgendwelche Ideen und Tipps wäre nett gewesen.

Answer 1

Ich habe sehr schnell einige erste Gedanken vor dem morgendlichen Treffen hier bei der Arbeit gemacht. Was denken Sie? Sollte dieser Ansatz näher betrachtet und untersucht werden? Es ist ein Pseudo-Code-Diskussionsformat hier und es ist in keiner Weise die komplette Reihe von Funktionen und Klassen, aber ich denke, die primäre IDs ist klar genug.

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

Ich werde diese Herausforderung auch annehmen, also können wir uns wahrscheinlich gegenseitig helfen. Ich werde nur einige meiner Gedanken zu dem hinzufügen, was Sie bereits skizziert haben.

Ich denke, eine Installation/uninstallController wäre Overkill resp. zu viel redundanter Code.

Was ist mit einem Installer-Kernmodul, das alle Installations- und Deinstallationsvorgänge der Software übernimmt. Dieses Modul würde dann nach install.ini suchen und ini-Dateien deinstallieren und die erforderlichen Aktionen entsprechend ausführen. Das Modul würde auch eine Standardoperation ausführen, wenn die Anweisungen in der install.ini fehlen. Auf diese Weise können Sie sicherstellen, dass Sie nur nicht standardmäßiges Verhalten in die INI-Dateien einfügen müssen.