Zend FR

blackarma · 20-05-2009 16:02:14

Bonjour,

J'ai une structure en module classic sous zend 1.8.1 et je m'interroge sur la meilleure manière de gérer plusieurs connexions BDD (entre autre ), je m'explique :

Chaque module à son fichier de configuration, et si pour un module une connexion BDD est définie dans le fichier de config je la créer et la stock dans le registry, je fait cela actuellement dans le bootstrap du module.

Le problème et que tous les fichiers Bootstrap son chargés par Zend or je ne veux que les connexion ne se fasse que lorsque l'utilisateur est dans le module spécifique (cela évite pas mal de consommation de ressource aussi).

J'avais pensé à récupérer l'objet Request depuis une metode _initXXX du bootstrap du module mais à ce stade l'objet n'est pas entièrement renseigné (moduleName = NULL, etc.).

Pour résumer : Le but est de ne charger que ce qui est nécessaire lorsque j'appelle une url du type /module/controller/action, je m'oriente vers du plugin en preDispatch. Mais ce plugin serait stocké dans un repertoire "plugins" du module, comment le déclarer correctement pour un chargement automatique seulement quand je suis dans ce module ?

(Le but étant de réellement isoler les composants de l'appli, le bootstrap et le fichier de config de Application n'étant la que pour la configuration "globale", le reste étant géré module par module.

Bref, si quelqun à une lampe torche, j'ai besoin de lumière...

Merci d'avoir lu jusqu'ici...

Dernière modification par blackarma (20-05-2009 17:07:59)

blackarma · 20-05-2009 17:12:26

Si j'ajoute ceci dans mon application.ini

test.resources.frontController.plugins[] = Test_Plugin_Test

et que dans application/modules/test/plugins/Test.php j'ai :

class Test_Plugin_Test extends Zend_Controller_Plugin_Abstract {

public function preDispatch(Zend_Controller_Request_Abstract $request) {
echo 'Plugin du module test : ' ;
echo $request->getModuleName();
}

}

quel que soit le module appelé le plugin est chargé...je ne veux le charger que lorsque le module appelé est Test...

Si quelqu'un a une idée, car sinon avec plusieurs modules et plusieurs plugins ca devient embêtant de tout charger ou de tout déclarer à la main...

Dernière modification par blackarma (20-05-2009 17:13:07)

pronorama · 30-05-2009 00:49:06

Bonjour,

Au vu du code contenu dans le fichier Zend/Controller/Front.php, je ne crois pas que cela soit possible de conditionner le chargement et l'exécution (appel des fonctions preDispatch, postDispatch, ...) d'un plugin, en fonction du module associé à l'action qui va être dispatchée.

Par contre, si j'ai bien compris ton problème, tu as dans ton fichier application.ini, une ressource "db" différente pour chaque module ?

...
module1.resources.db.adapter = "xxxx"
module1.resources.db.params.host = "aaaaaa"
...
module2.resources.db.adapter = "yyyy"
module2.resources.db.params.host = "bbbbbb"
...

et si tu créais un plugin (global, donc pas associé à un module en particulier) avec une fonction "preDispatch" qui récupère la ressource "db" associée au module de l'action qui va être exécutée par le front-controller, puis tu exploites cette ressource db à ta guise (mise dans le registre, en session, en adapter par défaut pour zend_db_table, ...) ?

class My_Controller_Plugin_ParametrageDb extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$front = Zend_Controller_Front::getInstance();
$bootstrap = $front->getParam('bootstrap');

$moduleEnCours = $request->getModuleName();
if ($moduleEnCours == $front->getDefaultModule()) {
$db = $bootstrap->getResource('db');
}
else {
$modules = $bootstrap->getPluginResource('modules');
$moduleBootstraps = $modules->getExecutedBootstraps();
$db = $moduleBootstraps[$moduleEnCours]->getResource('db');
}

...
... exemple : Zend_Db_Table_Abstract::setDefaultAdapter($db);
...
}
}

Si tu as un fichier .ini par module, le principe général restera le même (plugin + fonction preDispatch + determiner le .ini associé au module en cours + l'analyser et récupération le db spécifié, ...).

Philippe

blackarma · 01-06-2009 18:39:01

C'est clairement la meilleure solution, par contre je trouve bizarre cette manière de fonctionner dans ZF : chargement de tous les bootstrap et de tous les plugins quel que soit le module appelé...
Ca fait beaucoup de données chargées en mémoire pour rien...

Merci beaucoup pour ta solution !!!

blackarma · 02-06-2009 15:14:59

Au final pour bien compartimenter le tout j'ai un repertoire configs dans mes modules avec un fichier .ini qui porte le nom du module. Si dans ce fichier une ressource DB ou des plugins existent alors je charge les plugins et je recupere un objet DB configurer avec les valeures contenues dans le fichier ini et je le sauve en registry. Ca me donne ça :

Code:

class xxxx_Controller_Plugin_ModuleRessourceLoader extends Zend_Controller_Plugin_Abstract {

    public function dispatchLoopStartup (Zend_Controller_Request_Abstract $request) {
             
        // Récupération du nom du module appelé et des éléments de configuration
        // liés aux modules en général
        $moduleCalled = strtolower($request->getModuleName());
        $applicationConfig = Zend_Registry::get('config');
        $modulesDirectory = $applicationConfig->resources->frontController->moduleDirectory;
        $configDirectory = $applicationConfig->xxxx->modules->configDirectory;
        
        // Création du chemin du fichier de config du module actuellement appelé
        $configPath = $modulesDirectory . '/' .$moduleCalled . '/' . $configDirectory . '/' . $moduleCalled . '.ini'; 
        
        // Si il existe un tel fichier de configuration, on charge les plugins
        // déclarés dans le fichier de config et la connexion BDD pour ce module
        // si il en existe une...
        if (file_exists($configPath)) { 
            $front = Zend_Controller_Front::getInstance();
            $bootstrap = $front->getParam('bootstrap');
            $application = $bootstrap->getApplication();
            $configValues = new Zend_Config_ini($configPath, $application->getEnvironment());
            
            foreach($configValues->resources->frontController->plugins as $plugin) {
                $pluginName = ucfirst(strtolower($moduleCalled)) . '_Plugin_' . $plugin ;
                $front->registerPlugin(new $pluginName);
            }
            
            if(isset($configValues->resources->db)) {
                $db = Zend_Db::factory($configValues->resources->db);
                define('MODULE_DATABASE',$moduleCalled . 'Db');
                Zend_Registry::set(MODULE_DATABASE, $db);
            }
        }
    }
}

Qu'en penses-tu Pronorama??

Dernière modification par blackarma (02-06-2009 15:17:00)

pronorama · 03-06-2009 00:40:22

Pour ma part, j'en suis arrivé à la conclusion que la notion de "modules" telle que l'implémente le ZF n'est finalement qu'une manière de regrouper entre eux les controlleurs, vues, modèles, ... suivant des critères libres (fonctionnels, techniques, ...), ce qui n'est déjà pas si mal. Le paramétrage et l'amorcage (bootstrap) restant global et chargés "d'un bloc". Dans le bootstrap de chaque module, j'ai uniquement codé la fonction qui permet de déclarer le "namespace" associé au module :

protected function _initMyAutoload()
{
$autoloader = new Zend_Application_Module_Autoloader(array(
'namespace' => 'Xxxxxx_',
'basePath' => dirname(__FILE__),
));
return $autoloader;
}

De plus, je n'ai pas vraiment d'isolation complète entre mes modules. J'ai par exemple un module transverse "Layout" qui gère les layout (comme son nom l'indique) et dont les controlleurs (1 controlleur par layout) sont sollicités en fin de dispatching afin de construire le rendu final de la page (le choix du layout et d'un éventuel sous-layout étant définis via un helper d'action dans le module "fonctionnel")
Le FC peut donc être amené à déclencher en séquence des actions "hébergées" par des controlleurs de différents modules (j'empile les actions avec le plugin "actionStack").

Tu as vraiment une isolation complète entre les modules ? chacun ayant son propre paramétrage ?
Si c'est le cas, ça ne serait pas plus simple d'avoir carrément des applications différentes ????

Pour ton exemple, je n'ai jamais utilisé la fonction "dispatchLoopStartup" mais j'ai compris ce qu tu cherchais à faire, why not ! :-) Je trouve quand même dommage de devoir implémenter une gestion du paramètrage en complément de cette apportée par le Zend., mais je crois que tu n'as pas d'autres choix si tu veux garder tes modules dans la même appli !

A+

blackarma · 03-06-2009 13:08:55

Le concept de module implémenté par Zend ne me pose pas de souci au niveau de son architecture, mais le fait de tout charger me pose problème, car avec juste une connexion BDD la récupération d'une ligne et son affichage on a déjà atteint un pic de 7-8 MO de mémoire utilisé : ENORME !!

Alors avec des plugins des traitements à droite à gauche mon but est de réduire l'utilisation de mémoire.
D'oiu mon chargement des plugins généraux dans application.ini et le chargement des plugins du module appelé via son propre fichier ini.

++

Zend FR

#1 20-05-2009 16:02:14

[Modules][1.8.1] Bootstrap et connexion base de données multiples

#2 20-05-2009 17:12:26

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

#3 30-05-2009 00:49:06

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

#4 01-06-2009 18:39:01

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

#5 02-06-2009 15:14:59

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

Code:

#6 03-06-2009 00:40:22

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

#7 03-06-2009 13:08:55

Re: [Modules][1.8.1] Bootstrap et connexion base de données multiples

Pied de page des forums