Zend Framework - BootStrap
Date de publication : 21 octobre 2007
Par
JYT (Les expériences Zend de Sekaijin) (Blog)
Zend Framework a besoin pour démarrer de quelques petites choses, comme par exemple le chemin où trouver les contrôleurs ou encore les vues. Et bien d'autres encore.
I. Démarrage à froid
II. En passer par une config
III. Organiser la config.
IV. Améliorer le FrontController
I. Démarrage à froid
On trouve sur le net nombre d'exemples de BootStrap pour ZF qui expliquent comment ajouter telle ou telle option au démarrage.
<?php
$config = new Zend_Config(new Zend_Config_Ini('../application/config/config.ini', 'live'));
$sitemap = new Zend_Config(new Zend_Config_Ini('../application/config/sitemap.ini', 'live'));
$db = Zend_Db::factory($config->db->connection, $config->db->asArray());
...etc...
$auth = Zend_Auth::getInstance();
$acl = new MyAcl($auth);
$router = new Zend_Controller_RewriteRouter;
...add rules...
$view = new My_View;
...init view...
$front = Zend_Controller_Front::getInstance();
$front->throwExceptions(true);
$front->setRouter($router)
->setDispatcher(new Zend_Controller_ModuleDispatcher())
->registerPlugin(new My_Plugin_Auth($auth, $acl))
->registerPlugin(new My_Plugin_Agreement($auth))
->registerPlugin(new My_Plugin_View($view))
->setControllerDirectory(array('default' => realpath('../application/controllers/default'),
'admin' => realpath('../application/controllers/admin')))
->setParam('auth', $auth)
->setParam('view', $view)
->setParam('config', $config)
->setParam('sitemap', $sitemap)
->dispatch();
|
Si je m'en réfère à la documentation de ZF, le BootStrap est on ne peut plus simple :
<?php
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/chemin/vers/application/controllers');
|
Cette simplicité est séduisante, mais elle ne permet pas de personnaliser le démarrage.
Et devoir reproduire quelque chose d'aussi complexe que l'exemple ci-dessus est source d'erreurs.
II. En passer par une config
C'est pourquoi j'ai envisagé d'en passer par un fichier de configuration. Le BootStrap se résumant alors à charger la config, charger le front controller et le démarrer.
<?php
set_include_path(
realpath('library')
. PATH_SEPARATOR . realpath('application')
. PATH_SEPARATOR . get_include_path()
);
require 'Zend/Loader.php';
Zend_Loader::loadClass('Fast_Config');
Fast_Config::load();
Zend_Loader::loadClass('Zend_Controller_Front');
Zend_Controller_Front::run('application/controllers');
|
Notre BootStrap reste relativement simple et portable d'une application sur l'autre, les variations des options étant définies par la configuration.
Reste que Zend_Controller_Front ne sait pas utiliser mon Fast_Config. De plus, un fichier de configuration peut facilement devenir aussi compliqué que d'écrire un BootStrap.
III. Organiser la config.
Dans mon travail, mes développements se font de la façon suivante : le projet est géré avec CVS ou SVN, chaque développeur a une copie de l'application, et l'exécute sur un environnement qui lui est propre. L'application passe ensuite sur une plateforme de développement commune qui est identique à la plateforme cible et qui permet de tester les relations avec les autres applications lorsque cela est nécessaire. Ensuite, l'application est déployée sur une plateforme de recette. Celle-ci est destinée à la maîtrise d'ouvrage qui va valider l'application. Très souvent, l'étape suivante est une mise en pre production dont le but est de tester l'application en situation. Et, au final, elle est enfin placée sur son environnement de production. Il va sans dire qu'immanquablement tous ces environnements ne sont pas parfaitement identiques. La configuration de l'application va donc en dépendre pour partie.
À l'opposé, il existe toujours dans une application des paramètres qui ne sont pas liés à l'environnement. Pour ne pas avoir à systématiquement rééditer un gros fichier de configuration, j'ai pris l'habitude d'en faire plusieurs. En premier lieu, séparer ce qui est du paramétrage de l'application de ce qui est de la configuration due à l'environnement.
J'ai donc un fichier parameters qui définit les paramètres de l'application, et un fichier de configuration. Ce dernier existe en autant d'exemplaires que de plateformes (ou presque). Une solution pour sélectionner le bon est de le nommer config et de renommer les autres qui pourraient éventuellement traîner par là. L'inconvénient de cette approche est que lorsqu'on voit dans le dossier config le fichier config on ne sait pas à quel environnement il se rapporte. J'ai donc choisi de les nommer en fonction de l'environnement : dev, recette, preprod, prod, etc. Reste donc à indiquer au BootStrap lequel choisir. J'ai pour cela défini un fichier qui ne fait que ça : environnement.ini
Si vous regardez la hiérarchie que j'ai choisie dans l'article précédent, il faut déterminer où placer ces fichiers. Pour moi, il s'agit de la configuration de l'application. J'ai donc ajouté un dossier
config dans le
dossier application. J'y place les fichiers
environnement.ini,
parameters.ini et
dev.ini etc. Le dossier
application étant déjà protégé, la configuration n'est normalement pas accessible pour le client.
Comment déterminer ce que l'on place dans parameters et ce qui va dans dev ou autre ? Il suffit pour cela de se poser la question « l'attribut de configuration doit-il changer si je change de plateforme ? » Par exemple, l'option « utiliser les ACL » ne dépend pas de l'endroit où l'on place l'application. C'est un paramètre. En revanche, « database host » dépend de la plateforme : il va donc dans la config.
Ainsi, le passage d'une plateforme à l'autre se résume à créer un fichier config propre à la plateforme et à changer la valeur d'environnement.ini.
Cette façon de faire n'est peut-être pas la meilleure, mais elle a fait ses preuves.
Apprendre au Front_Controller à utiliser la config.
IV. Améliorer le FrontController
La seule approche que permet par défaut ZF pour configurer le Front Controller est d'en passer par le BootStrap. Mais ZF est une belle architecture à objets, qui autorise l'héritage et le polymorphisme. Je vais me servir de cette caractéristique pour construire un Front_Controller paramétrable par la configuration.
Fast_Controler_Front va donc dériver de Zend_Controller_Front et fournir les mêmes fonctionnalités mais, au passage, il va utiliser la configuration pour ajouter seul, les options demandées.
Pour cela, il suffit de surcharger la méthode statique run :
<?php
require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Controller_Front');
@author
@author
@uses
@package
class Fast_Controller_Front extends Zend_Controller_Front
{
51
@paramstringarray$controllerDirectory
array
@return
object
public static function run($controllerDirectory)
{
$config = Fast_Registry::getConfiguration();
$parameters = Fast_Registry::getParameters();
if ($parameters&&$config) {
…
} else {
Zend_Controller_Front::run('application/controllers');
}
}
}
|
Ainsi dans notre BootStrap, nous pouvons garder un code simplifié, il suffit d'utiliser Fast_Controller_Front à la place de Zend_Controller_Front :
<?php
set_include_path(
realpath('library')
. PATH_SEPARATOR . realpath('application')
. PATH_SEPARATOR . get_include_path()
);
require 'Zend/Loader.php';
Zend_Loader::loadClass('Fast_Config');
Fast_Config::load();
Zend_Loader::loadClass('Fast_Controller_Front');
Fast_Controller_Front::run('application/controllers');
|
Notez que j'ai pris la précaution de lancer un Zend_Controller_Front si je n'ai pas de config, permettant ainsi de garder le fonctionnement par défaut de ZF.
Je n'ai abordé ici que la structure générale. La mise en œuvre fera l'objet d'une publication future.


Copyright © 2007 Sekaijin. Aucune reproduction, même partielle, ne peut être faite
de ce site et de l'ensemble de son contenu : textes, documents, images, etc
sans l'autorisation expresse de l'auteur.
Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E
de dommages et intérêts.
Cette page est déposée à la
SACD.