ZF Zend Framework

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 du dispatching 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 :

<?php
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 : <?php 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 à la méthode noRender() du ViewRenderer : <?php 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.

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 :

<?php
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'
        ));
    }
}

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()).

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

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.

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

7.7.5.2. Effectuer le rendu des Vues

render() a la signature suivante :

<?php
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.

Note

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 dispatcheur 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 :

<?php
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();
    }
}

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).

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.

<?php
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);
    }
}

<?php
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 dispatching 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 :

<?php
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.