Utilisation de conventions de dossiers modulaires

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 :

    • Les erreurs d'absence de contrôleurs ou d'actions

    • Erreurs survenant dans un contrôleur

    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 :

    1. $front->throwExceptions(true);
    2. try {
    3.     $front->dispatch();
    4. } catch (Exception $e) {
    5.     // A vous de gérer ici
    6. }

    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 :

    1. $front->returnResponse(true);
    2. $response = $front->dispatch();
    3. if ($response->isException()) {
    4.     $exceptions = $response->getException();
    5.     // Gestion des exceptions ici
    6. } else {
    7.     $response->sendHeaders();
    8.     $response->outputBody();
    9. }

    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 :

      1. $front->setParam('useDefaultControllerAlways', true);
      2. // ou
      3. $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 :

      1. class My_Controller_Action extends Zend_Controller_Action
      2. {
      3.     public function __call($method, $args)
      4.     {
      5.         if ('Action' == substr($method, -6)) {
      6.             $controller = $this->getRequest()->getControllerName();
      7.             $url = '/' . $controller . '/index';
      8.             return $this->_redirect($url);
      9.         }
      10.  
      11.         throw new Exception('Invalid method');
      12.     }
      13. }

      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 :

      1. class My_Controller_Dispatcher extends Zend_Controller_Dispatcher
      2. {
      3.     public function getAction($request)
      4.     {
      5.         $action = $request->getActionName();
      6.         if (empty($action)) {
      7.             $action = $this->getDefaultAction();
      8.             $request->setActionName($action);
      9.             $action = $this->formatActionName($action);
      10.         } else {
      11.             $controller = $this->getController();
      12.             $action     = $this->formatActionName($action);
      13.             if (!method_exists($controller, $action)) {
      14.                 $action = $this->getDefaultAction();
      15.                 $request->setActionName($action);
      16.                 $action = $this->formatActionName($action);
      17.             }
      18.         }
      19.  
      20.         return $action;
      21.     }
      22. }

      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 :

      1. class My_Controller_PreDispatchPlugin
      2.       extends Zend_Controller_Plugin_Abstract
      3. {
      4.     public function preDispatch(Zend_Controller_Request_Abstract $request)
      5.     {
      6.         $front      = Zend_Controller_Front::getInstance();
      7.         $dispatcher = $front->getDispatcher();
      8.         $class      = $dispatcher->getControllerClass($request);
      9.         if (!$controller) {
      10.             $class = $dispatcher->getDefaultControllerClass($request);
      11.         }
      12.  
      13.         $r      = new ReflectionClass($class);
      14.         $action = $dispatcher->getActionMethod($request);
      15.  
      16.         if (!$r->hasMethod($action)) {
      17.             $defaultAction  = $dispatcher->getDefaultAction();
      18.             $controllerName = $request->getControllerName();
      19.             $response       = $front->getResponse();
      20.             $response->setRedirect('/' . $controllerName
      21.                                   . '/' . $defaultAction);
      22.             $response->sendHeaders();
      23.             exit;
      24.         }
      25.     }
      26. }

      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.


Utilisation de conventions de dossiers modulaires