Contactez-nous
Kitpages
17 rue de la Frise
38000 Grenoble
tel : 04 58 00 33 81
Plugins et helpers du MVC du Zend Framework
Introduction
Cette page décrit le fonctionnement général du MVC du Zend Framework et précise le rôle et l'utilisation des Plugins et des Helpers.
Note : cet article ne s'adresse pas aux débutants sur le Zend Framework. Il faut être déjà bien familiarisé avec ce framework pour comprendre l'intérêt de cet article.
Le schéma général
Avant de parler des plugins et helpers, voilà un schéma général indiquant ce qui se passe quand le ZF affiche une page avec le MVC.
Je vous invite à cliquer dessus pour l'agrandir. Voilà quelques éléments d'information pour comprendre la base. Je reviendrai plus tard sur les détails.
Les flèches numérotées indiquent les étapes successives suivies par le Framework et nécessaires pour afficher une page. Le nom écrit au dessus de la flèche est souvent le nom de la méthode appelée. (Il manque des étapes, j'ai limité ce schéma aux étapes importantes).
- Il y a 4 éléments en beige. Ce sont les éléments sur lesquels le développeur peut réellement intervenir
- index.php : le bootstrap
- plugins : les plugins (on y reviendra)
- MyController : le controlleur que vous écrivez (IndexController par exemple)
- Helpers : les helpers (on y reviendra)
- Les autres briques sont des éléments internes du Zend Framework
Revenons sur les grandes étapes :
- 1 et 2 : le navigateur de l'internaute fait une requête. La requête arrive sur apache. Apache réécrit la requête pour l'envoyer sur index.php
- 3 : index.php (le bootstrap) configure le Zend Framework et appelle la fonction dispatch de Front.php (Zend_Controller_Front)
- 4 à 13 : le ZF fait le routage (détermine quel module/controller/action il faut appeler), regarde si des plugins sont enregistrés et appelle ces plugins si besoin
- 14 à 16 : Votre controlleur est instancié (new...) et sa fonction init est appelée
- 17 à 19 : on regarde si des helpers sont enregistrés et on appelle leur fonction preDispatch, ainsi que la fonction preDispatch du controlleur
- 20 : l'action demandée par l'URL est appelée (par exemple indexAction de la classe IndexController est appelée)
- 21 à 23 : les fonctions postDispatch des helpers et controlleurs sont appelées
- 24 à 25 : on ressort de votre controlleur, à partir de là il a fait tout son boulot, il n'est plus accessible (je dis ça pour bien montrer que dans les étapes suivantes, le plugin n'a pas accès à votre controlleur)
- 26 à 29 : on appelle les fonctions postDispatch des plugins enregistrés
- 30 à fin : on renvoie la réponse à l'internaute.
Notons que les étapes 12 à 27 peuvent être répétées plusieurs fois, notamment dans le cas de l'utilisation de $this->_forward.
C'est un peu indigeste, mais c'est important de comprendre ces étapes pour comprendre les plugins et helpers...
Les plugins
Un plugin est appelé avant l'instanciation de votre controlleur ou après la fin de son exécution.
Il permet donc
- d'influer sur un routage
- de vérifier des droits d'accès (et donc de modifier le routage si l'internaute n'a pas les droits nécessaires)
- ...
Par contre votre controlleur n'est pas encore créé, il ne peut donc pas modifier ajouter une variable dans votre controlleur...
Voilà un exemple de plugin simple. Supposons que vous ayez une page accessible à l'adresse http://monsite/index/home
Ce plugins vous permet d'appeler l'action "newhome" à la place de l'action "home" dans IndexController.
<?php
class Kitpages_SimplePlugin
extends Zend_Controller_Plugin_Abstract {
public function preDispatch
(Zend_Controller_Request_Abstract $request) {
$ctrlName = $request->getControllerName();
$actionName = $request->getActionName();
if (($ctrlName == "index") && ($actionName=="home") ) {
$request->setActionName("newhome")
}
}
}
?>
// enregistrement dans index.php
<?php
//...
$controller->registerPlugin(new Kitpages_SimplePlugin());
//...
?>
Notons que dans l'exemple précédent, nous avons redéfini preDispatch. Vous pouvez redéfinir d'autre méthodes (routeStartup, routeShutdown, dispatchLoopStartup, preDispatch, postDispatch, dispatchShutdown). Allez voir le schéma général pour voir à quels moments interviennent ces méthodes.
Les Helpers
Attention : je parle ici des helpers du controlleur. Ils n'ont rien à voir avec les view helpers. Les view helpers n'ont rien à voir avec ce tutoriel.
Un helper est appelé une fois que le routage est terminé :
- les modules/controller/action sont choisis
- le controlleur est réellement créé
- à partir de là les helpers entrent en jeux
Notons quelques points supplémentaires sur les helpers :
- Ils n'ont pas vocation à modifier le routage. Théoriquement ils sont appelés quand le controller et l'action sont "définitivement" choisis
- Le controlleur est déjà instancié, ils peuvent donc interagir avec le controlleur et c'est là leur intérêt principal
- Les helpers permettent notamment de faire des opérations systématiquement sur tous vos controlleurs sans avoir à répéter le code dans toutes vos actions.
L'exemple suivant montre un helper très simple qui permet de rendre accessible la session très simplement dans toutes les actions.
On suppose ici que la session a été ajoutée dans la registry. L'objectif est d'y accéder dans chaque action sans avoir à faire appel à la registry.
<?php
class Kitpages_SimpleHelper
extends Zend_Controller_Action_Helper_Abstract {
public function preDispatch() {
$session = Zend_Registry::get("session");
$this->getActionController()->session = $session;
}
}
?>
// ainsi dans vos actions, on peut accéder
// facilement à la session avec $this->session
<?php
class IndexController extends Zend_Controller_Action {
public function indexAction() {
//...
$language = $this->session->language;
//...
}
}
?>
// pour l'enregistrer dans index.php
<?php
$myHelper = new Kitpages_SimpleHelper();
Zend_Controller_Action_HelperBroker::addHelper($myHelper);
?>
Comme pour les plugins, on peut définir plusieurs fonctions dans un helper : preDispatch et postDispatch. Allez voir le schéma général pour comprendre à quels étapes ils interviennent.
Notons également que dans vos controlleurs, vous pouvez définir 3 méthodes : init, preDispatch et postDispatch. preDispatch et postDispatch jouent le même rôle que dans un helper, mais ils sont limités à un seul controlleur. La fonction init() est appelée juste après l'instanciation de votre controlleur et avant l'appel à tous les helpers et preDispatch.
Conclusion
Une fois que l'on a compris le fonctionnement général du MVC du ZF, les helpers et les plugins s'y intègrent assez naturellement. Ils s'avèrent très pratiques pour mutualiser du code et proposent un système souvent plus souple que l'héritage.
Les plugins sont principalement destinés à gérer les problèmes de routage.
Les helpers sont utilisés pour tous les traitements que vous seriez tentés de recopier dans toutes vos actions.
N'hésitez pas à m'envoyer des remarques ou des question sur le forum de http://www.z-f.fr. Je traine souvent là bas !
Commentaires
Note : on ne peut plus ajouter de commentaire sur ce site