Initialisation modulaire et bootstraping

**s.n.a.f.u** · 09/07/2009, 11h29

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

**s.n.a.f.u** · 10/07/2009, 16h35

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

mes deux classes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ini :

Sélectionner tout - Visualiser dans une fenêtre à part

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 php :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

**s.n.a.f.u** · 10/07/2009, 16h48

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

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/

**Eusebe** · 10/07/2009, 20h55

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

**s.n.a.f.u** · 11/07/2009, 10h11

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.