PluginsIntroductionL'architecture MVC de Zend Framework propose l'injection de plugins de code, qui vont intervenir à différents niveaux dans le processus complet. Le contrôleur frontal enregistre des plugins, et utilise un gestionnaire de plugins ("plugin broker"), qui va se charger de faire intervenir chaque plugin, à chacun des instants clés à votre disposition. Les instants clés sont des méthodes événementielles définies dans la classe abstraite Zend_Controller_Plugin_Abstract, dont tous les plugins doivent hériter :
Écrire des pluginsTous les plugins doivent hériter de Zend_Controller_Plugin_Abstract:
Comme aucune des méthodes de Zend_Controller_Plugin_Abstract n'est abstraite, vous n'êtes pas obligé dans vos plugins de toutes les définir. Vous agissez aux endroits que vous voulez. Zend_Controller_Plugin_Abstract vous donne aussi accès aux objets de réponse et de requête, dans vos plugins. getRequest() et getResponse() sont là pour ça. Cependant, l'objet de requête est de toute façon passé en paramètre à vos méthodes. Veillez à le récupérer dans la définition de vos méthodes sinon une erreur E_STRICT sera levée. Utilisation des pluginsLes plugins sont enregistrés avec Zend_Controller_Front::registerPlugin(), et peuvent l'être n'importe quand. Voici un exemple :
Si aucune autre action ne génère une sortie (typiquement, un rendu de vue), alors le résultat suivant devrait s'afficher :
Récupération et manipulations des pluginsIl peut arriver que vous ayez besoin de récupérer des plugins, ou d'en supprimer. Les méthodes suivantes vous seront alors utiles :
Plugins inclus dans Zend FrameworkZend Framework possède des plugins dans sa distribution : ActionStack
Le plugin Vous pouvez récupérer ce plugin grâce à Zend_Controller_Front::getPlugin('Zend_Controller_Plugin_ActionStack'). Une fois l'objet retourné, voici les méthodes qui y sont proposées :
La méthode forward(), elle, est directe : elle attend un objet de requête qu'elle passe immédiatement au contrôleur frontal en redemandant un jeton de distribution. Zend_Controller_Plugin_ErrorHandlerZend_Controller_Plugin_ErrorHandler est un plugin intégré par défaut pour gérer les exceptions levées par votre application, il sert à gérer les exceptions envoyées par l'application, en particulier celles concernant des contrôleurs ou des actions manquants. C'est une manière rejoignant la section Exceptions MVC. Les principaux objectifs de ce plugin sont :
Globalement, ErrorHandler sert à gérer les erreurs HTTP 404 ou 500. Attention, le plugin n'est pas destiné à intervenir sur les exceptions envoyées dans d'autres plugins. Des effets de bords peuvent apparaître, veillez à les gérer. Par défaut, Zend_Controller_Plugin_ErrorHandler redirige vers ErrorController::errorAction() dans le module par défaut. Vous pouvez passer d'autres valeurs via les accesseurs du plugin :
Ce comportement fonctionne aussi avec le constructeur du plugin. Celui-ci agit comme un proxy vers setErrorHandler(). Zend_Controller_Plugin_ErrorHandler agit en postDispatch() et analyse l'objet de réponseà la recherche d'éventuelles exceptions. Si il y en a, alors le plugin modifie la requête pour distribuer le contrôleur et l'action d'erreur. Si une exception arrive lorsque le plugin agit, alors celui-ci ordonne au contrôleur frontal de renvoyer l'exception, et relance la dernière exception enregistrée dans l'objet de réponse. Utilisation de ErrorHandler pour gérer les erreurs 404Comme ErrorHandler capture les exceptions relatives à un problème de contrôleur ou action manquants, vous pouvez donc l'utiliser comme un gestionnaire d'erreurs 404. Pour cela, il faut analyser le type d'exception ayant mené à l'erreur. Les exceptions capturées sont enregistrées en tant que paramètre d'action. Zend_Controller_Action::_getParam('error_handler'):
Une fois que vous possédez l'objet contenant l'exception, inspectez son type avec $errors->type;. Des constantes sont à votre disposition :
Les trois premiers types pourraient mener à une erreur 404 :
Enfin, il est possible de récupérer l'exception ayant menée au contrôleur d'erreur. Ceci afin de l'analyser. L'attribut exception de l'objet error_handler le permet :
Gestion des rendus précédants de la réponseSi vous décomposez vos processus en plusieurs actions ou plusieurs appels à render(), il est possible que la réponse contienne déjà des éléments. Ceci peut introduire un mélange entre le rendu attendu et le contenu de l'erreur. Si vous désirez rendre votre contrôleur d'erreur dans ce contenu, alors il n'y a rien à faire de spécial. En revanche, il peut aussi être judicieux de vider totalement la réponse afin de rendre le contrôleur d'erreurs. Procédez alors comme suit :
Exemples d'utilisationExample #1 Utilisation standard et désactivation Example #2 Paramétrage du plugin
Example #3 Utilisation des accesseurs
Exemple de contrôleur d'erreursPour utiliser le plugin de gestion d'erreurs, un contrôleur d'erreurs est requis. En voici un exemple :
Zend_Controller_Plugin_PutHandlerZend_Controller_Plugin_PutHandler fournit un plugin intégré pour la gestion du corps des requêtes PUT en tant que paramètres de requête, tout comme le corps d'une requête POST. Il va inspecter la requête et, s'il s'agit d'une requête PUT, va utiliser la fonction parse_str pour découper le contenu brut de la requête PUT en un tableau de paramètres qui est ensuite enregistré dans l'objet de requête. Par exemple :
Pour recevoir les paramètres "title" et "body" comme des paramètres de requête habituels, vous devez enregistrer le plugin : Ensuite vous pouvez accéder aux paramètres du corps de la requête PUT par leur nom à l'intérieur de votre contrôleur :
|
|