Initialisation modulaire et bootstraping

Bonjour,

Je continue dans mon exploitation des modules sous ZF.
Ca se passe pas mal, mais je voudrais maintenant utiliser (et comprendre) une initialisation modulaire, c'est à dire spécifique à un module.

Pour exemple, je voudrais initialiser un layout suivant le module utilisé, ou me connecter à une base spécifique, etc...

Mon premier problème est au niveau du bootstrap: d'après mes tests, ZF exécute TOUS les Module_Bootstrap !

Dans mon appli, j'ai un module "private" et un module "admin"
Dans Private_Bootstrap et Admin_Bootstrap (qui étendent bien sûr Zend_Application_Module_Bootstrap), j'ai juste codé une méthode _initTest qui affiche un message : 'hello private' ou 'hello admin'.
Quelle ne fut pas ma surprise de voir les deux messages lorsque j'entre une url http://monsite.fr/private/controller/action

=> le module Admin est bootstrappé alors qu'il n'est pas utilisé. Est-ce normal ?

Si oui, je ne peux utiliser les Module_Bootstrap pour mon initialisation spécifique.
Quelle est alors la bonne manière de procéder ?

D'avance merci,

SNAF

Je viens de me mettre à jour en 1.8.4 et il n'y a pas de changement.

mes deux classes :

Code:

---

1 2 3 4 5 6 7 8 9

<?php class Private_Bootstrap extends Zend_Application_Module_Bootstrap {   protected function _initMsg() { Zend_Debug::dump('hello private'); }   }

---

Code:

---

1 2 3 4 5 6 7

class Admin_Bootstrap extends Zend_Application_Module_Bootstrap {   protected function _initMsg() { Zend_Debug::dump('hello admin'); }   }

---

Les deux bootstrap sont exécutés quelle que soit l'url et je vois mes deux hello

le fichier de config application.ini utilisé par Zend_Application :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

production] phpSettings.display_startup_errors = 0 phpSettings.display_errors = 0   bootstrap.path = APPLICATION_PATH "/Bootstrap.php" bootstrap.class = "Bootstrap"   resources.frontController.baseUrl = "/monsite" resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers" resources.frontController.moduleDirectory = APPLICATION_PATH "/modules" resources.frontController.defaultModule = "default"   resources.modules = ""   resources.layout.layout = "layout" resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"   resources.view.encoding = "UTF-8"   resources.db.adapter = "PDO_SQLITE" resources.db.params.dbname = APPLICATION_PATH "/db.db3" resources.db.isDefaultTableAdapter = true

---

Le Bootstrap et son autoLoad :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap {   protected function _initAutoload() { $autoloader = new Zend_Application_Module_Autoloader(array( 'namespace' => '', 'basePath' => dirname(__FILE__) )); return $autoloader; }   protected function _initDb() { $db = $this->getPluginResource('db')->getDbAdapter(); $db->setFetchMode(Zend_Db::FETCH_OBJ); Zend_Db_Table_Abstract::setDefaultAdapter($db); Zend_Registry::set('db', $db); }   }

---

Quelqu'un pourrait-il déjà me dire pourquoi tous les boostraps sont lancés ?

Ah, ah ! Je crois que je tiens un article valable !

Citation:

---

There is some confusion regarding the resources initialized by the module bootstraps. Many people think that these resource methods and plugins are executed only if the request maps to a controller belonging to this module. This is not the case. As the sequence diagram below shows, these methods and plugins are executed well before the front controller is dispatched. Thus, any code in the module bootstraps affects the whole application. This is contrary to most people’s expectations, mostly because the term module bootstrap implies otherwise. Rather than a module bootstrap, one should think of them as scattered parts of the application bootstrap that are organized per module. This limits the usefulness of the module bootstrap to registering plugins, helpers, helper paths and routes as they are the things that are unlikely to conflict with other bootstraps. However, these are plenty useful by themselves, and module-specific behavior can be defined through a plugin registered by the module bootstrap. But that’s a topic for another post.

---

=> http://monzee.wordpress.com/2009/06/...ons-in-zf-1-8/

Citation:

---

Envoyé par s.n.a.f.u

Ah, ah ! Je crois que je tiens un article valable !

=> http://monzee.wordpress.com/2009/06/...ons-in-zf-1-8/

---

En effet, voilà une belle réponse :ccool:

Citation:

---

There is some confusion regarding the resources initialized by the module bootstraps. Many people think that these resource methods and plugins are executed only if the request maps to a controller belonging to this module. This is not the case. As the sequence diagram below shows, these methods and plugins are executed well before the front controller is dispatched. Thus, any code in the module bootstraps affects the whole application.

---

Je pense que cela mériterait d'être précisé dans un tuto ou autre, parce que j'ai un peu galèré pour trouver cette info.

Bonjour,

Si j'ai bien compris il est donc inutile d'initialiser les bootstrap des différents modules, vu qu'il sont tous lancés

Citation:

---

Envoyé par aityahia

Bonjour,

Si j'ai bien compris il est donc inutile d'initialiser les bootstrap des différents modules, vu qu'il sont tous lancés

---

Ce n'est pas complètement inutile ;)

Ca permet déjà de séparer clairement les éléments d'initialisation spécifiques à certains modules.

Citation:

---

Envoyé par Eusebe

Ce n'est pas complètement inutile ;)

Ca permet déjà de séparer clairement les éléments d'initialisation spécifiques à certains modules.

---

Je ne suis pas tout à fait d'accord : on ne peut pas prétendre faire de l'initialisation spécifique lorsqu'elle est tout le temps réalisée, que le module soit utilisé ou pas. J'avoue ne pas beaucoup aimer la façon de gérer ce genre d'initialisation.

Citation:

---

Envoyé par s.n.a.f.u

Je ne suis pas tout à fait d'accord : on ne peut pas prétendre faire de l'initialisation spécifique lorsqu'elle est tout le temps réalisée, que le module soit utilisé ou pas. J'avoue ne pas beaucoup aimer la façon de gérer ce genre d'initialisation.

---

Entièrement d'accord avec snafu

je crois que la solution est d'utilisé des helpers pour basculer les configurations entres les différents modules, comme on peut le voir dans cet article pour l'initialisation du layout.

http://devzone.zend.com/article/4747...Zend-Framework

Pour une question d'organisation de code, même si c'est systématiquement exécuté, il ne me parait pas complètement inutile de séparer les initialisations spécifiques des différents modules.

Et pour ce qui est d'initialiser un plugin uniquement pour un module donné, ça me parait difficile dans l'état actuel du Framework, la résolution de la route étant réalisée après cette initialisation... (d'ailleurs la méthode routeStartup() des plugins est exécutée avant de savoir dans quel module on se trouve).

Je me penche sur la question en ce moment. Il me semble que la piste du plugin devrait aboutir et je ne manquerais pas de vous faire part de mon expérience.

Sinon, vous faites comment vous ? :koi:

J'avais laissé tombé le plugin pour cause de problème d'autoload.

J'ai donc fait une première tentative en utilisant l'héritage de Zend_Controller_Action

Le nom du module en question est "private", situé dans APPLICATION_PATH/modules/

Je créée tout d'abord mon contrôleur abstrait qui effectuera l'initialisation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<?php abstract class Private_Controller_Abstract extends Zend_Controller_Action {   protected $_flash; protected $_redirector; protected $_auth; protected $_log;   public function init() { $this->_flash = $this->_helper->getHelper('FlashMessenger'); $this->_redirector = Zend_Controller_Action_HelperBroker::getStaticHelper('Redirector'); $this->_log = Zend_Registry::get('log'); $this->_auth = Zend_Auth::getInstance(); if (!$this->_auth->hasIdentity()) $this->_redirector->gotoSimple(null, null, 'login'); }   }

---

J'utilise ensuite tout simplement ce contrôleur en le dérivant. Et pour l'initialisation, je n'oublie pas d'appeler parent::init():

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

<?php class Private_IndexController extends Private_Controller_Abstract {   public function init() { parent::init(); // --> tout se joue ici ! $this->view->user = $this->_auth->getIdentity()->login; $this->view->admin = $this->_auth->getIdentity()->isAdmin; $this->view->logged = TRUE; }   public function indexAction() { }     }

---

Tout pourrait aller pour le mieux dans le meilleur des mondes, mais mon appli ne trouve pas mon contrôleur perso. Flûte ! Qu'ais-je oublié ? Mais oui! L'autoload !

Je veux absolument que mon contrôleur abstrait soit dans le module, et non pas dans une autre librairie externe.
Je vais donc ajouter une ressource à mon autoloader de module, que j'aurais préalablement récupéré.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?php class Private_Bootstrap extends Zend_Application_Module_Bootstrap {   protected function _initAutolader() { /* le bootstrap créée pour moi un Module_Autoloader.   * je le récupère pour y ajouter le chemin de mes controllers perso   */ $autoloader = Zend_Loader_Autoloader::getInstance(); $myLoaders = $autoloader->getNamespaceAutoloaders('Private'); $loader = array_shift($myLoaders); $loader ->addResourceType('ctl', 'controllers', 'Controller'); return $loader; }       }

---

Et ça marche au poil. Qu'en pensez-vous ?

Etape suivante : traduire cette démarche en utilisant un plugin ou une aide d'action. Ce sera encore plus flexible et plus évolutif.

A suivre...

Jetez un œil à ça, j'ai pas eu le temps de l'étudier, mais je crois que c'est une approche intéressante.

http://blog.keppens.biz/2009/06/zend...ic-config.html