# Contrôleurs d'action

## Introduction

`Zend_Controller_Action` est une classe abstraite que vous pouvez utiliser avec le contrôleur frontal quand vous construisez un site Web basé sur le modèle de conception Modèle-Vues-Contrôleurs (MVC).

Pour utiliser `Zend_Controller_Action`, vous devez la sous-classer dans vos propres classes de contrôleurs d'action (ou la sous-classer pour créer votre propre classe de base pour vos contrôleurs d'action). L'opération la plus basique est de la sous-classer, et de créer vos méthodes d'action qui correspondent aux différentes actions que vous souhaitez gérer. La gestion du routage et de la distribution des `Zend_Controller` va rechercher automatiquement les méthodes dont le nom termine par 'Action' dans votre classe et les considérer comme des actions potentiellement valides de votre contrôleur.

Par exemple, considérons une classe définie comme ceci :

    class FooController extends Zend_Controller_Action
    {
        public function barAction()
        {
            // réalise quelquechose
        }

        public function bazAction()
        {
            // réalise quelquechose
        }
    }

La classe FooController (contrôleur foo) définit deux actions, bar et baz.

Il y a d'autres fonctionnalités qui peuvent être utilisées, comme personnaliser l'initialisation des actions, gérer les actions par défaut quand aucune action ou une action invalide est fournie, avoir la possibilité de hook ("détournement") en pre et post-dispatch, et une variété de méthodes d'aides (helper). Ce chapitre fournit une vue d'ensemble des fonctionnalités du contrôleur d'action.

### Comportement par défaut

Par défaut, le contrôleur frontal active l'aide d'action ViewRenderer. Cette aide s'occupe de l'injection automatique de l'objet de vue dans vos contrôleurs, ainsi que du rendu de cette vue. Vous pouvez la désactiver au sein de vos contrôleurs par l'une ou l'autre des actions suivantes :

    class FooController extends Zend_Controller_Action
    {
        public function init()
        {
            // Locale à ce seul contrôleur ; affecte toutes les actions,
            // si chargée dans l'init :
            $this->_helper->viewRenderer->setNoRender(true);

            // Global :
            $this->_helper->removeHelper('viewRenderer');

            // Global aussi, mais doit être réalisé en conjonction avec
            // la version locale pour être propagé dans ce contrôleur:
            Zend_Controller_Front::getInstance()->setParam('noViewRenderer',
                                                           true);
        }
    }

Les méthodes `initView()`, `getViewScript()`, `render()`, et `renderScript()` sont affectées chacune au ViewRenderer à moins que l'aide ne soit pas chargée dans le gestionnaire d'aide (helper broker) ou que l'option noViewRenderer n'ait été réglée.

Vous pouvez simplement désactiver le rendu pour une vue individuelle grâce au drapeau noRender du ViewRenderer :

    class FooController extends Zend_Controller_Action
    {
        public function barAction()
        {
            // désactive le rendu automatique pour cette action seulement :
            $this->_helper->viewRenderer->setNoRender();
        }
    }

Les raisons principales de désactiver le ViewRenderer sont l'absence de besoin d'objets de vues ou si vous n'effectuez pas de rendu via des scripts de vues (par exemple, quand vous utilisez un contrôleur d'action pour servir des protocoles de service Web comme SOAP, XML-RPC, ou REST). Dans la plupart des cas, il n'est pas nécessaire de désactiver globalement le ViewRenderer, seulement de manière sélective pour des contrôleurs ou actions individuels.

## Initialisation d'objet

Même si vous pouvez toujours surcharger le constructeur du contrôleur d'action, nous ne vous le recommandons pas. `Zend_Controller_Action::__construct()` réalise certaines tâches importantes, comme l'enregistrement des objets de requêtes et de réponses, ainsi que l'invocation d'arguments personnalisés fourni par le contrôleur frontal. Si vous devez surcharger le constructeur, n'oubliez pas d'appeler `parent::__construct($request, $response, $invokeArgs)`.

La manière la plus appropriée de personnaliser l'instanciation est d'utiliser la méthode `init()`, qui est appelée en dernière tâche de `__construct()`. Par exemple, si vous voulez vous connecter à une base de données à l'instanciation :

    class FooController extends Zend_Controller_Action
    {
        public function init()
        {
            $this->db = Zend_Db::factory('Pdo_Mysql', array(
                'host'     => 'myhost',
                'username' => 'user',
                'password' => 'XXXXXXX',
                'dbname'   => 'website'
            ));
        }
    }

## Détournement Pre et Post-Dispatch (Hook)

`Zend_Controller_Action` spécifie deux méthodes qui peuvent être appelées juste avant et juste après une action, `preDispatch()` et `postDispatch()`. Celles-ci peuvent être pratiques dans plusieurs cas : vérifier l'authentification et les ACL avant d'exécuter une action (en appelant `_forward()` dans `preDispatch()`, l'action sera évitée), par exemple, ou en plaçant du contenu généré dans une partie du modèle du site (`postDispatch()`).

### Utilisation de init() ou de preDispatch()

Dans la section précédente, nous avons introduit la méthode `init()`, et dans celle-ci, la méthode `preDispatch()`. Quelles sont leurs différences, et quelles actions vont-elles réaliser chacune ?

La méthode `init()` a pour but principal d'étendre le constructeur. Typiquement, votre constructeur devrait simplement paramétrer les états des objets, mais pas réaliser d'opérations logiques. Ceci peut inclure l'initialisation des ressources utilisées dans le contrôleur (comme des modèles, des objets de configuration, etc.), ou assigner des valeurs issues du contrôleur frontal, du fichier d'amorçage, ou d'un registre.

La méthode `preDispatch()` peut aussi être utilisée pour paramétrer un objet ou un environnement (par exemple, une vue, une aide d'action, etc.), mais son but principal est d'établir des décisions autorisant ou non une action requêtée à être distribuée. Si elle ne l'est pas, vous pouvez alors utiliser `_forward()` vers une autre action, ou lancer une exception.

Note: la méthode `_forward()` s'exécutera pas correctement si elle est appelée depuis `init()`, ce qui est une formalisation des intentions de deux méthodes.

## Accesseurs

Un certain nombre d'objets et de variables sont enregistrés avec l'objet et chacun possède des méthodes accesseurs.

- Objet Requête : `getRequest()` peut être utilisé pour récupérer l'objet de requête utilisé pour appeler l'action.

- Objet Réponse : `getResponse()` peut être utilisé pour récupérer l'objet de réponse assemblant la réponse finale. Quelques appels typiques peuvent ressembler à ceci :

      $this->getResponse()->setHeader('Content-Type', 'text/xml');
      $this->getResponse()->appendBody($content);

- Arguments d'invocation : le contrôleur frontal peut transmettre des paramètres au routeur, au distributeur, et au contrôleur d'action. Pour récupérer individuellement ceux-ci utilisez `getInvokeArg($key)` ; alternativement, récupérer la liste entière en utilisant `getInvokeArgs()`.

- Paramètres de requêtes : l'objet de requête rassemble les paramètres de requête, comme les paramètres `_GET` ou _`_POST`, ou les paramètres utilisateurs spécifiés dans le chemin d'URL. Pour récupérer ceux-ci utilisez `_getParam($key)` ou `_getAllParams()`. Vous pouvez aussi régler ces paramètres en utilisant `_setParam()` ; ceci est pratique quand vous redirigez vers des actions additionnelles.

  Pour tester si un paramètre existe ou non (pratique pour les branchements logiques), utilisez `_hasParam($key)`.

  `_getParam()` peut prendre un second paramètre optionnel contenant une valeur par défaut à utiliser si le paramètre n'est pas réglé ou qu'il est vide. Utiliser ceci élimine la nécessité d'appeler `_hasParam()` avant de récupérer une valeur :

      // Utilise une valeur par défaut de 1 si id n'est pas réglé
      $id = $this->_getParam('id', 1);

      // Au lieu de :
      if ($this->_hasParam('id') {
          $id = $this->_getParam('id');
      } else {
          $id = 1;
      }

## Intégration des Vues

### Par défaut, l'intégration des vues est réalisé via le ViewRenderer

Le contenu de cette section n'est valable que si vous avez explicitement désactivé le ViewRenderer. Sinon, vous pouvez passer à la section suivante.

`Zend_Controller_Action` fournit un mécanisme rudimentaire et flexible pour l'intégration des vues. Deux méthodes accomplissent ceci, `initView()` et `render()` ; la première méthode charge la propriété publique `$view`, et la dernière effectue le rendu d'une vue basé sur l'action courante demandée dans la requête, en utilisant la hiérarchie des répertoires pour déterminer le chemin du script.

### Initialisation des Vues

`initView()` initialise l'objet Vue. `render()` appelle `initView()` dans le but de récupérer l'objet de vue, mais il peut être initialisé à tout moment ; par défaut il remplit la propriété `$view` avec un objet `Zend_View`, mais toute classe implémentant `Zend_View_Interface` peut être utilisée. Si `$view` est déjà initialisé, il retourne simplement cette propriété.

La mise en oeuvre par défaut suppose la structure de répertoire suivante :

    applicationOrModule/
        controllers/
            IndexController.php
        views/
            scripts/
                index/
                    index.phtml
            helpers/
            filters/

En d'autres termes, les scripts de vues sont supposés être dans le sous-répertoire `/views/scripts/`, et le sous-répertoire `/views/` est censé contenir les fonctionnalités soeurs (aides [helpers], filtres [filters]). En déterminant le script de vue et son chemin, le répertoire `/views/scripts/` est utilisé comme chemin de base, avec des dossiers nommés par le nom de contrôleur fournissant ainsi la hiérarchie des scripts de vues.

### Effectuer le rendu des Vues

`render()` a la signature suivante :

    string render(string $action = null,
                  string $name = null,
                  bool $noController = false);

`render()` effectue le rendu d'un script de vue. Si aucun argument n'est fourni, la méthode suppose que le script requêté est `[controller]/[action].phtml` (où `.phtml` est la valeur de la propriété `$viewSuffix`). Fournir une valeur pour `$action` va effectuer le rendu du script dans le sous-dossier `/[controller]/`. Pour surcharger l'utilisation du sous-dossier `/[controller]/`, fournissez la valeur `TRUE` à `$noController`. Enfin, les scripts sont rendus dans l'objet réponse ; si vous souhaitez effectuer le rendu dans un segment nomméspécifique de l'objet réponse, fournissez une valeur à `$name`.

Puisque le contrôleur et des noms d'action peuvent contenir des caractères délimiteurs de mot comme '_', '.' et '-', `render()` normalise ceux-ci à '-' en déterminant le nom du script. En interne, il utilise le délimiteur de mot et de chemin du istributeur pour faire cette normalisation. Ainsi, une requête pour `/foo.bar/baz-bat` rendra le script `foo-bar/baz-bat.phtml`. Si votre méthode d'action contient des notationsCamel, veuillez vous souvenir que ceci va résulter avec des mots séparés par '-' en déterminant le nom de fichier du script de vue.

Quelques exemples :

    class MonController extends Zend_Controller_Action
    {
        public function fooAction()
        {
            // Effectue le rendu de mon/foo.phtml
            $this->render();

            // Effectue le rendu de mon/bar.phtml
            $this->render('bar');

            // Effectue le rendu de baz.phtml
            $this->render('baz', null, true);

            // Effectue le rendu de mon/login.phtml vers le segment
            // 'form' de l'objet réponse
            $this->render('login', 'form');

            // Effectue le rendu de site.phtml vers le segment
            // 'page' de l'objet réponse ; sans utiliser
            // le sous-dossier 'mon/'
            $this->render('site', 'page', true);
        }

        public function bazBatAction()
        {
            // Effectue le rendu de mon/baz-bat.phtml
            $this->render();
        }
    }

## Méthodes utiles

En plus de l'accesseur et des méthodes d'intégration de vue, `Zend_Controller_Action` possède plusieurs méthodes utiles pour exécuter des tâches communes de l'intérieur de vos méthodes d'action (ou de pre- / post-dispatch).

- `_forward($action, $controller = null, $module = null, array $params = null)` : exécute une autre action. Si appelé dans `preDispatch()`, la requête courante est évitée en faveur de la nouvelle. Sinon, après que l'action courante ait été exécutée, l'action demandée dans `_forward()` sera exécutée à son tour.

- `_redirect($url, array $options = array())` : redirige vers une autre page. Cette méthode prend un URL et un jeu d'options optionnel. Par défaut, il exécute une redirection de type HTTP 302.

  Les options peuvent inclure une ou plusieurs des clés suivantes :

  - : avec ou sans sortie immédiate. Si appelée, la méthode fermera proprement toute session ouverte et réalisera la redirection.

    Vous pouvez régler cette option de manière globale dans le contrôleur en utilisant l'accesseur `setRedirectExit()`.

  - prependBase : ajoute ou non l'URL de base enregistré dans l'objet requête à l'URL produit.

    Vous pouvez régler cette option de manière globale dans le contrôleur en utilisant l'accesseur `setRedirectPrependBase()`.

  - code : fournit le code HTTP à utiliser pour la redirection. Par défaut, un HTTP 302 est utilisé ; tout code compris entre 301 et 306 peut être utilisé.

    Vous pouvez régler cette option de manière globale dans le contrôleur en utilisant l'accesseur `setRedirectCode()`.

## Sous-classer le contrôleur d'action

Par conception, `Zend_Controller_Action` doit être sous-classé pour créer un contrôleur d'action. Au minimum, vous devez définir les méthodes d'action que le contrôleur d'action peut appeler.

En plus de la création de fonctionnalité utile pour vos applications Web, vous pouvez aussi constater que vous répétez souvent la même installation ou les mêmes méthodes utilitaires dans vos contrôleurs divers ; s'il en est ainsi, créer une classe de contrôleur de base commune qui étend `Zend_Controller_Action` peut résoudre une telle redondance.

### Comment gérer des actions non-existantes

Si une requête vers un contrôleur est faite en incluant une méthode d'action indéfinie, `Zend_Controller_Action::__call()` sera invoqué. `__call()` est, bien sûr, la méthode magique de PHP pour la surcharge de méthode.

Par défaut, cette méthode lève une `Zend_Controller_Action_Exception` indiquant que la méthode requêtée n'a pas été trouvée dans le contrôleur. Si la méthode requêtée se termine par "Action", on considère qu'une action était requêté et qu'elle n'existe pas ; un telle erreur entraîne une exception ayant un code 404. Tout autre appel de méthode entraîne une exception ayant un code 500. Ceci vous permet de facilement différencier une page inconnue et une erreur de l'application dans votre gestionnaire d'erreur.

Vous pouvez surcharger cette fonctionnalité si vous souhaitez exécuter d'autres opérations. Par exemple, si vous souhaitez afficher un message d'erreur, vous pouvez écrire quelque chose comme ceci :

    class MonController extends Zend_Controller_Action
    {
        public function __call($method, $args)
        {
            if ('Action' == substr($method, -6)) {
                // Si une méthode d'action n'est pas trouvée,
                // rendre le script d'erreur
                return $this->render('error');
            }

            // pour toute autre méthode, levée d'une exception
            throw new Exception('Méthode invalide "' . $method . '" appelée',
                                500);
        }
    }

Une autre possibilité est de rediriger vers une page de contrôleur par défaut :

    class MyController extends Zend_Controller_Action
    {
        public function indexAction()
        {
            $this->render();
        }

        public function __call($method, $args)
        {
            if ('Action' == substr($method, -6)) {
                // Si une méthode d'action n'est pas trouvée,
                // rediriger vers l'action index
                return $this->_forward('index');
            }

            // pour tout autre méthode, levée d'une exception
            throw new Exception('Méthode invalide "' . $method . '" appelée',
                                500);
        }
    }

En plus de la surcharge de `__call()`, chacune des méthodes d'initialisation , utilitaires, d'accesseurs, de vues et de détournement de la distribution mentionnées ci-dessus peuvent être surchargées dans le but de personnaliser vos contrôleurs. Par exemple, si vous stockez votre objet de vue dans le registre, vous pouvez vouloir modifier votre méthode `initView()` avec une code comme celui-ci :

    abstract class Ma_Base_Controller extends Zend_Controller_Action
    {
        public function initView()
        {
            if (null === $this->view) {
                if (Zend_Registry::isRegistered('view')) {
                    $this->view = Zend_Registry::get('view');
                } else {
                    $this->view = new Zend_View();
                    $this->view->setBasePath(dirname(__FILE__) . '/../views');
                }
            }

            return $this->view;
        }
    }

En espérant que les informations de ce chapitre vous permettent de voir la flexibilité de ce composant particulier et comment vous pouvez le modifier suivant les besoins de votre application.