Previous Next

Le contrôleur frontal (Front Controller)

Présentation générale

Zend_Controller_Front implémente un » motif de contrôleur frontal utilisé dans les applications » Modèle-Vue-Contrôleur (MVC). Son but est d'initialiser l'environnement de requête, d'acheminer la requête entrante et de dispatcher ensuite n'importe quelles actions découvertes ; il agrège n'importe quelles réponses et les retourne quand le processus est complet.

Zend_Controller_Front implémente aussi le » motif Singleton, signifiant que seule une instance du contrôleur frontal peut être disponible à n'importe quel moment. Cela lui permet aussi d'agir comme un enregistrement dans lequel les autres objets du processus de dispatching peuvent écrire.

Zend_Controller_Front enregistre un plugin broker avec lui, permettant à des événements divers qu'il déclenche d'être observés par plugins. Dans la plupart des cas, cela donne au développeur l'occasion de construire le processus de dispatching au site sans avoir besoin d'étendre le contrôleur frontal pour ajouter une fonctionnalité.

Le contrôleur frontal a besoin au minimum d'un ou plusieurs répertoires contenants les contrôleurs d'action pour faire son travail. Une variété de méthodes peut aussi être invoquée pour plus tard construire l'environnement de contrôleur frontal et celui de ses classes d'aide.

Note: Comportement par défaut

Par défaut, le contrôleur frontal charge le plugin ErrorHandler, ainsi que le plugin d'aide d'action ViewRenderer. Ceci est fait respectivement pour simplifier la gestion d'erreur et le rendu des vues dans vos contrôleurs.

Pour désactiver ErrorHandler, exécutez l'action suivante à n'importe quel point précédant l'appel à dispatch() :

setParam('noErrorHandler', true);

Pour désactiver ViewRenderer, exécutez l'action suivante à n'importe quel point précédant l'appel à dispatch() :

setParam('noViewRenderer', true);

Méthodes principales

Le contrôleur frontal a plusieurs accesseurs pour construire son environnement. Cependant, il y a trois méthodes principales clés dans la fonctionnalité de contrôleur frontal :

getInstance()

getInstance() est utilisé pour récupérer une instance du contrôleur frontal. Comme le contrôleur frontal implémente un motif de Singleton, c'est aussi le seul moyen possible pour instancier un objet unique de contrôleur frontal.



        

setControllerDirectory() et addControllerDirectory

setControllerDirectory() est utilisé pour informer le dispatcheur où chercher les fichiers de classes de contrôleurs d'action. Ces méthodes acceptent un chemin unique ou un tableau associatif de paires modules/chemins.

Quelques exemples :

// Régler le dossier des contrôleurs par défaut :
$front->setControllerDirectory('../application/controllers');

// Régler plusieurs répertoires de modules d'un seul coup :
$front->setControllerDirectory(array(
    'default' => '../application/controllers',
    'blog'    => '../modules/blog/controllers',
    'news'    => '../modules/news/controllers',
));

// Ajouter le répertoire de module 'foo' :
$front->addControllerDirectory('../modules/foo/controllers', 'foo');

Note:

Si vous utilisez addControllerDirectory() sans nom de module, cela réglera le répertoire pour le module default - en surchargeant une valeur déjà existante.

Vous pouvez récupérer les réglages courants des répertoires du contrôleur en utilisant getControllerDirectory() ; ceci retournera un tableau des paires modules/chemins.

dispatch()

dispatch(Zend_Controller_Request_Abstract $request = null, Zend_Controller_Response_Abstract $response = null) fait le gros travail du contrôleur frontal. Il peut facultativement prendre un objet de requête et/ou un objet de réponse, permettant ainsi au développeur de fournir des objets personnalisés.

Si aucun objet de requête ou de réponse ne lui sont fournis, dispatch() vérifiera s'il existe des objets précédemment enregistrés et utilisera ceux-là ou des objets par défaut pour les utiliser dans son processus (dans les deux cas, le mode HTTP sera utilisé par défaut).

De la même manière, dispatch() vérifie s'il existe des objets routeur et dispatcheur inscrits, et instancie des versions par défaut si aucun n'est trouvé.

Le processus de dispatching possède trois évènements

  • le routage

  • le dispatching

  • la réponse

Le routage a lieu exactement une fois, utilisant les valeurs de l'objet de requête quand dispatch() est appelé. Le dispatching a lieu dans une boucle ; une demande peut soit indiquer des actions multiples à dispatcher, soit le contrôleur ou un plugin peuvent remettre à zéro l'objet de requête et ainsi forcer le dispatching d'actions supplémentaires. Quand tout est réalisé, le contrôleur frontal retourne la réponse.

run()

Zend_Controller_Front::run($path) est une méthode "raccourci", statique, prenant simplement un chemin vers un répertoire contenant des contrôleurs. Elle récupère l'instance de contrôleur frontal (via getInstance()), enregistre le chemin fourni par l'intermédiaire de setControllerDirectory(), et finalement réalise le dispatching.

Fondamentalement, run() est une méthode de convenance qui peut être employée pour les installations de sites qui n'exigent pas la personnalisation de l'environnement du contrôleur frontal.



        

Méthodes d'accès à l'environnement

En plus des méthodes énumérées ci-dessus, il y a un certain nombre de méthodes d'accès qui peuvent être employées pour affecter l'environnement de contrôleur frontal - et ainsi l'environnement des classes auxquelles le contrôleur frontal délégue.

  • resetInstance() peut être utilisé pour effacer tous les réglages courants. Son but principal est pour les tests, mais elle peut également être employée pour des instances où vous souhaitez enchaîner ensemble les contrôleurs frontaux multiples.

  • (set|get)DefaultControllerName() vous permet d'indiquer un nom différent pour l'utilisation du contrôleur par défaut ("index" est employé sinon) et de rechercher la valeur courante. Ils mandatent le dispatcheur.

  • (set|get)DefaultAction() vous permet d'indiquer un nom différent pour l'utilisation de l'action par défaut ("index" est employé sinon) et de rechercher la valeur courante. Ils mandatent le dispatcheur.

  • (set|get)Request() vous permet d'indiquer la classe ou l'objet de requête à utiliser durant le processus de dispatching et de rechercher la valeur courante. En réglant l'objet de requête, vous pouvez fournir le nom d'une classe de requête, dans ce cas la méthode chargera le fichier de classe et l'instanciera.

  • (set|get)Router() vous permet d'indiquer la classe ou l'objet de routage à utiliser durant le processus de dispatching et de rechercher la valeur courante. En réglant l'objet de routage, vous pouvez fournir le nom d'une classe de routage, dans ce cas la méthode chargera le fichier de classe et l'instanciera.

    Lors de la recherche d'un objet routeur, cela vérifie d'abord si un objet est présent, et sinon, instancie le routeur par défaut ("rewrite router").

  • (set|get)BaseUrl() vous permet d'indiquer l'URL de base à écarter lors du routage des requêtes et de rechercher la valeur courante. La valeur est fournie à l'objet de requête juste avant le routage.

  • (set|get)Dispatcher() vous permet d'indiquer la classe ou l'objet dispatcheur à utiliser durant le processus de dispatching et de rechercher la valeur courante. En réglant l'objet de dispatching, vous pouvez fournir le nom d'une classe de dispatching, dans ce cas la méthode chargera le fichier de classe et l'instanciera.

    Lors de la recherche d'un objet dispatcheur, cela vérifie d'abord si un objet est présent, et sinon, instancie le dispatcheur par défaut.

  • (set|get)Response() vous permet d'indiquer la classe ou l'objet de réponse à utiliser durant le processus de dispatching et de rechercher la valeur courante. En réglant l'objet de réponse, vous pouvez fournir le nom d'une classe de réponse, dans ce cas la méthode chargera le fichier de classe et l'instanciera.

  • registerPlugin(Zend_Controller_Plugin_Abstract $plugin, $stackIndex = null) vous permet d'inscrire un objet plugin. En réglant le paramètre facultatif $stackIndex, vous pouvez contrôler l'ordre dans lequel les plugins seront exécutés.

  • unregisterPlugin($plugin) vous permet de désinscrire un objet plugin. $plugin peut être soit un objet plugin ou une chaîne représentant la classe du plugin à désinscrire.

  • throwExceptions($flag) est utilisée pour activer/désactiver la possibilité de lever des exceptions durant le processus de dispatching. Par défaut, les exceptions sont récupérées et placées dans l'objet réponse ; activer throwExceptions() surchargera ce comportement et indiquera au contrôleur frontal de ne pas enregistrer le plugin de gestion des erreurs : ErrorHandler.

    Pour plus d'informations, voir Exceptions avec MVC.

  • returnResponse($flag) est utilisée pour informer le contrôleur frontal soit de récupérer la réponse (true) issue de dispatch(), ou si la réponse peut être automatiquement émise (false). Par défaut la réponse est automatiquement émise (en appelant Zend_Controller_Response_Abstract::sendResponse()) ; activer returnResponse() surchargera ce comportement.

    Les raisons de la récupération de la réponse incluent le désir de vérifier l'existence d'exceptions avant d'émettre la réponse, la nécessité d'enregistrer certains aspects de la réponse (comme les entêtes), etc.

Paramètres du contrôleur frontal

Dans l'introduction, nous avons indiqué que le contrôleur frontal agit également en tant qu'enregistreur pour les divers composants du contrôleur. Il réalise ceci grâce à une famille de méthodes "param". Ces méthodes vous permettent d'enregistrer des données arbitraires - objets et variables - que le contrôleur frontal peut rechercher à tout moment dans la chaîne de dispatching. Ces valeurs sont transmises au routeur, au dispatcheur, et aux contrôleurs d'action. Les méthodes incluent :

  • setParam($name, $value) vous permet de régler un paramètre unique nommé $name avec la valeur $value.

  • setParams(array $params) vous permet de régler des paramètres multiples en une seule fois en utilisant un tableau associatif.

  • getParam($name) vous permet de récupérer un unique paramètre, en utilisant $name comme identificateur.

  • getParams() vous permet de récupérer la liste entière des paramètres.

  • clearParams() vous permet d'effacer un paramètre unique (en fournissant l'identificateur sous forme de chaîne), des paramètres multiples (en fournissant un tableau d'identificateurs sous forme de chaîne), ou tous les paramètres (en ne fournissant rien).

Il y a plusieurs paramètres prédéfinis qui peuvent être réglés et qui ont des utilisations spécifiques dans la chaîne d'expédition :

  • useDefaultControllerAlways() est utilisée pour informer le dispatcheur d'utiliser le contrôleur par défaut dans le module par défaut pour toute requête qui ne serait pas dispatchable (par exemple si le module/contrôleur/action n'existe pas). Par défaut, cette fonctionnalité est désactivée.

    Voir Différents types d'exceptions que vous pouvez rencontrer pour plus d'informations concernant l'utilisation de ce réglage.

  • disableOutputBuffering() est utilisée pour informer le dispatcheur qu'il ne doit pas utiliser l'"output buffering" pour capturer le rendu généré par les contrôleurs d'action. Par défaut, le dispatcheur capture tout rendu et l'ajoute au contenu de l'objet réponse.

Sous-classer le contrôleur frontal

Pour sous-classer le contrôleur frontal, vous devez au minimum surcharger la méthode getInstance() :

class Mon_Controleur_Frontal extends Zend_Controller_Front
{
    public static function getInstance()
    {
        if (null === self::$_instance) {
            self::$_instance = new self();
        }

        return self::$_instance;
    }
}

Surcharger la méthode getInstance() assure que des appels suivants à Zend_Controller_Front::getInstance() retourneront une instance de votre nouvelle sous-classe au lieu d'une instance de Zend_Controller_Front - c'est particulièrement utile pour certains des routeurs alternatifs et certaines aides de vue.

Typiquement, vous n'aurez pas besoin de sous-classer le contrôleur frontal à moins que vous ne deviez ajouter une nouvelle fonctionnalité (par exemple, un plugin d'autoloader, ou une manière d'indiquer des chemins d'aide d'action). Quelques exemples où vous pouvez vouloir changer le comportement peuvent inclure modifier comment des répertoires de contrôleur sont stockés, ou quel routeur ou dispatcheur par défaut sont employés.

Previous Next
Introduction to Zend Framework
Présentation
Installation
Zend_Acl
Introduction
Affiner les Contrôles d'Accès
Utilisation avancée
Zend_Auth
Introduction
Authentification avec une table de base de données
Authentification "Digest"
Adaptateur d'authentification HTTP
LDAP Authentication
Authentification OpenID
Zend_Cache
Introduction
La théorie du cache
Les frontends Zend_Cache
Les backends Zend_Cache
Zend_Captcha
Introduction
Captcha Operation
Captcha Adapters
Zend_Config
Introduction
Point de vue théorique
Zend_Config_Ini
Zend_Config_Xml
Zend_Console_Getopt
Introduction à Getopt
Déclarer les règles Getopt
Extraire les options et les arguments
Configurer Zend_Console_Getopt
Zend_Controller
Zend_Controller - Démarrage rapide
Fondations de Zend_Controller
Le contrôleur frontal (Front Controller)
L'objet Requête
Routeur Standard : Zend_Controller_Router_Rewrite
Le dispatcheur
Contrôleurs d'action
Aides d'action (Helper)
Objet de réponse
Plugins
Utilisation de conventions de dossiers modulaires
Exceptions avec MVC
Migrer depuis des versions précédentes
Zend_Currency
Introduction à Zend_Currency
How to work with currencies
Migrer depuis des versions antérieures
Zend_Date
Introduction
Point de vue théorique
Méthodes de base
Zend_Date API Overview
Créer des dates
Constants for General Date Functions
Exemples concrets
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Relations Zend_Db_Table
Zend_Debug
Afficher des informations
Zend_Dojo
Introduction
Zend_Dojo_Data: dojo.data Envelopes
Les aides de vues Dojo
Les éléments de formulaire et les décorateurs Dojo
Zend_Dom
Introduction
Zend_Dom_Query
Zend_Exception
Utiliser les exceptions
Zend_Feed
Introduction
Importer des flux
Obtenir des flux à partir de pages Web
Consommer un flux RSS
Consommer un flux Atom
Consommer une entrée Atom particulière
Modifier la structure du flux ou des entrées
Classes personnalisées pour les flux et entrées
Zend_File
Zend_File_Transfer
Validators for Zend_File_Transfer
Zend_Filter
Introduction
Classes de filtre standards
Chaînes de filtrage
Écriture de filtres
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Zend_Form Quick Start
Creating Form Elements Using Zend_Form_Element
Creating Forms Using Zend_Form
Creating Custom Form Markup Using Zend_Form_Decorator
Standard Form Elements Shipped With Zend Framework
Standard Form Decorators Shipped With Zend Framework
Internationalization of Zend_Form
Advanced Zend_Form Usage
Zend_Gdata
Introduction à Gdata
Authentification par procédé AuthSub
Authentification avec ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Utiliser l'API YouTube
Utilisation des albums Web Picasa
Attraper les exceptions Gdata
Zend_Http
Zend_Http_Client - Introduction
Zend_Http_Client - Utilisation avancée
Zend_Http_Client - Adaptateurs de connexion
Zend_Http_Cookie and Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Introduction
Zend_Json
Introduction
Utilisation de base
Objets JSON
XML to JSON conversion
Zend_Json_Server - JSON-RPC server
Zend_Layout
Introduction
Zend_Layout - Démarrage rapide
Zend_Layout options de configuration
Zend_Layout, utilisation avancée
Zend_Ldap
Introduction
Zend_Loader
Charger les fichiers et les classes dynamiquement
Chargeur de Plugins
Zend_Locale
Introduction
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported Languages for Locales
Supported Regions for Locales
Zend_Log
Présentation
Rédacteurs (Writers)
Formateurs (mise en forme)
Filtres
Zend_Mail
Introduction
Envoyer des emails en utilisant SMTP
Envoyer plusieurs emails par connexion SMTP
Utiliser différents transports
Email HTML
Fichiers joints
Ajouter des destinataires
Contrôler les limites MIME
Entêtes additionnelles
Jeux de caractères
Encodage
Authentification SMTP
Sécuriser les transports SMTP
Lire des emails
Zend_Measure
Introduction
Création d'une mesure
Récupérer des mesures
Manipuler des mesures
Types de mesures
Zend_Memory
Présentation
Manager de mémoire
Objet mémoire
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_OpenId
Introduction
Zend_OpenId_Consumer Basics
Zend_OpenId_Provider
Zend_Paginator
Introduction
Usage
Configuration
Advanced usage
Zend_Pdf
Introduction.
Créer et charger des documents PDF
Sauvegarder les changement dans un document PDF
Les pages d'un document
Dessiner
Informations du document et métadonnées.
Exemple d'utilisation du module Zend_Pdf
Zend_Registry
Utiliser le registre
Zend_Rest
Introduction
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Overview
Building Indexes
Searching an Index
Query Language
Query Construction API
Character Set
Extensibility
Interoperating with Java Lucene
Advanced
Best Practices
Zend_Server
Introduction
Zend_Server_Reflection
Zend_Service
Introduction
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Introduction
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Zend_Service_Technorati
Zend_Service_Yahoo
Zend_Session
Introduction
Usage basique
Utilisation avancée
Global Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Accessor
AutoDiscovery. Introduction
Class autodiscovering.
Functions autodiscovering.
Autodiscovering. Datatypes.
Zend_Test
Introduction
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_TimeSync
Introduction
Utiliser Zend_TimeSync
Zend_Translate
Introduction
Adaptateurs pour Zend_Translate
Utiliser les adaptateurs de traduction
Zend_Uri
Zend_Uri
Zend_Validate
Introduction
Classes de validation standard
Chaînes de validation
Ecrire des validateurs
Zend_Version
Lire la version du Zend Framework
Zend_View
Introduction
Scripts de contrôleur
Scripts de vue
Aides de vue
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Introduction
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Configuration système requise par le Zend Framework
Version de PHP requise
Extensions PHP
Les composants du Zend Framework
Dépendances internes du Zend Framework
Convention de codage PHP du Zend Framework
Vue d'ensemble
Formatage des fichiers PHP
Conventions de nommage
Style de codage
Informations de copyright