Exceptions avec MVC
Introduction
Les composants MVC de Zend Framework utilisent un contrôleur frontal, ce qui veut
dire que toute requête envoyée à l'application entre par ce point unique. Ainsi, toutes
les exceptions sont encapsulées dans le contrôleur frontal, ceci vous permet de toutes
les traiter dans un seul endroit.
Cependant, les exceptions peuvent contenir des messages ou des traces plutôt
sensibles pour le système, comme des requêtes SQL, l'emplacement de certains fichiers
... Pour vous aider à protéger votre site, par défaut,
Zend_Controller_Front attrape toutes les exceptions et les
enregistre dans l'objet de réponse ; et bien entendu, par défaut, cet objet de réponse
n'affiche pas ces exceptions.
Gestion des exceptions
Plusieurs mécanismes vont vous permettre de traiter les exceptions dans le modèle
MVC de Zend Framework.
-
Par défaut, le plugin
error
handlerest présent, et activé. Ce plugin a été conçu pour gérer :
ErrorHandler agit dans le postDispatch(), et
analyse si une exception a été levée (en gérant son type). Si c'est le cas,
alors le plugin renvoie un jeton vers un contrôleur de gestion des
erreurs.
Ce contrôleur couvrira la majorité des cas d'utilisation. Il parvient à
gérer les cas "contrôleur absent", "action absente", ou "autre cas".
-
Zend_Controller_Front::throwExceptions()
En passant la valeur TRUE à cette méthode, vous indiquez au
contrôleur frontal que vous souhaitez qu'il vous retourne les exceptions qu'il
rencontre. Ainsi, il ne les ajoutera pas à la réponse, et il ne fera pas
intervenir le plugin "Error handler ". Exemple :
$front->throwExceptions(true);
try {
$front->dispatch();
} catch (Exception $e) {
// A vous de gérer ici
}
Cette méthode vous permet d'utiliser une gestion personnalisée des
exceptions dans votre application, de manière simple.
-
Zend_Controller_Response_Abstract::renderExceptions()
En passant un paramètre TRUE à cette méthode, vous indiquez
à la réponse d'afficher les exceptions qu'elle reçoit (du contrôleur frontal,
ou du plugin "Error handler ", par exemple), lorsque son rendu est
appelé. Ceci ne devrait être activé qu'en environnement de développement.
-
Zend_Controller_Front::returnResponse() et
Zend_Controller_Response_Abstract::isException().
En passant le booléen TRUE à
Zend_Controller_Front::returnResponse(),
Zend_Controller_Front::dispatch() ne commandera pas
l'affichage de la réponse automatiquement. Au lieu de cela, l'objet de réponse
sera retourné. Vous pouvez alors tester celui-ci pour voir s'il contient des
exceptions, ceci grâce à isException() et
getException(). Voyez :
$front->returnResponse(true);
$response = $front->dispatch();
if ($response->isException()) {
$exceptions = $response->getException();
// Gestion des exceptions ici
} else {
$response->sendHeaders();
$response->outputBody();
}
Par rapport à
Zend_Controller_Front::throwExceptions(), cette
utilisation vous permet de ne rendre la réponse que lorsque vous le décidez,
selon la présence de telle ou telle exception, ou pas.
Différents types d'exceptions que vous pouvez rencontrer
Les composants MVC sont nombreux, - requête, routeur, distributeur, contrôleur,
et réponse - chaque objet risque de renvoyer une exception qui lui est propre.
Certaines peuvent être créées ou dérivées, d'autres par défaut indiquent un problème de
l'application.
Comme exemples :
-
Zend_Controller_Dispatcher::dispatch() va envoyer
une exception, par défaut, si un contrôleur invalide est demandé. Vous pouvez
jouer sur ce paramètre :
-
Initialisez le paramètre
useDefaultControllerAlways
Dans votre contrôleur frontal, ou distributeur, ajoutez la
directive suivante :
$front->setParam('useDefaultControllerAlways', true);
// ou
$dispatcher->setParam('useDefaultControllerAlways', true);
Lorsque ceci est injecté, le distributeur utilisera le contrôleur
par défaut s'il s'aperçoit qu'il ne peut distribuer un contrôleur
spécifique, plutôt que de renvoyer une exception. Méfiez vous des
moteurs de recherche qui n'aiment pas que plusieurs URI pointent sur un
même contenu. En effet, avec ce paramètre activé, les utilisateurs
orthographiant mal votre site, seront redirigés vers la page d'accueil
de celui-ci, ce qui peut aboutir à du "duplicate content" (contenu
dupliqué).
-
L'exception envoyée par dispatch() est de type
Zend_Controller_Dispatcher_Exception et contient
le message "Invalid controller specified". Utilisez une méthode comme
vu dans la
section
précédentepour attraper celle-ci et rediriger vers une page
d'erreur générique.
-
Zend_Controller_Action::__call() enverra une
Zend_Controller_Action_Exception s'il n'est pas possible
de distribuer l'action demandée. Il est facile de changer ce
comportement :
-
Dérivez la classe Zend_Controller_Action
en redéfinissant sa méthode __call(), voyez plutôt :
class My_Controller_Action extends Zend_Controller_Action
{
public function __call($method, $args)
{
if ('Action' == substr($method, -6)) {
$controller = $this->getRequest()->getControllerName();
$url = '/' . $controller . '/index';
return $this->_redirect($url);
}
throw new Exception('Invalid method');
}
}
Cet exemple intercepte les actions non existantes, et redirige
vers l'action principale du contrôleur actuel.
-
Dérivez Zend_Controller_Dispatcher et
redéfinissez getAction() pour vérifier si l'action existe
bien :
class My_Controller_Dispatcher extends Zend_Controller_Dispatcher
{
public function getAction($request)
{
$action = $request->getActionName();
$action = $this->getDefaultAction();
$request->setActionName($action);
$action = $this->formatActionName($action);
} else {
$controller = $this->getController();
$action = $this->formatActionName($action);
$action = $this->getDefaultAction();
$request->setActionName($action);
$action = $this->formatActionName($action);
}
}
return $action;
}
}
L'exemple précédant vérifie si l'action existe dans le contrôleur
demandé. Si ce n'est pas le cas, il redéfinit l'action en spécifiant
celle par défaut.
Cette méthode permet de changer l'action avant la distribution.
Attention une fois encore aux erreurs de syntaxes dans l'URL, qui
devraient mener vers une page d'erreur quelconque.
-
Utilisez
Zend_Controller_Action::preDispatch() ou
Zend_Controller_Plugin_Abstract::preDispatch()
pour identifier les actions invalides.
En dérivant Zend_Controller_Action pour y
modifier preDispatch(), vous agissez sur la globalité de
vos contrôleurs, avant même la distribution de l'action
demandée.
L'utilisation d'un plugin offre une flexibilité supplémentaire :
Si tous vos contrôleurs n'héritent pas de la même classe, plutôt que de
dupliquer du code, un plugin va agir indépendamment de vos contrôleurs.
En preDispatch(), il agit avant ceux-ci.
Par exemple :
class My_Controller_PreDispatchPlugin
extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$front = Zend_Controller_Front::getInstance();
$dispatcher = $front->getDispatcher();
$class = $dispatcher->getControllerClass($request);
if (!$controller) {
$class = $dispatcher->getDefaultControllerClass($request);
}
$r = new ReflectionClass($class);
$action = $dispatcher->getActionMethod($request);
if (!$r->hasMethod($action)) {
$defaultAction = $dispatcher->getDefaultAction();
$controllerName = $request->getControllerName();
$response = $front->getResponse();
$response->setRedirect('/' . $controllerName
. '/' . $defaultAction);
$response->sendHeaders();
}
}
}
Dans cet exemple, nous vérifions si l'action demandée existe dans
le contrôleur distribué. Si ce n'est pas le cas, nous exécutons une
redirection immédiate.
|
|