L'utilisation de base des composants MVC n'a pas changé ; vous pouvez toujours faire comme suit :

Nous encourageons l'utilisation de l'objet Réponse pour agréger le contenu et les en-têtes. Ceci permet un basculement plus flexible entre les formats d'affichage (par exemple, JSON ou XML au lieu de XHTML) dans vos applications. Par défaut, dispatch() va effectuer le rendu de la réponse, envoyant à la fois les en-têtes et tout contenu. Vous pouvez aussi avoir le contrôleur frontal qui retourne la réponse en utilisant returnResponse(), et qui ensuite effectue le rendu de la réponse suivant votre propre logique. Une version future du contrôleur frontal peut mettre en application l'utilisation de l'objet Réponse via la » bufferisation de sortie.

Il existe beaucoup d'autres fonctionnalités qui étendent l'API existante, et celles-ci sont décrites dans la documentation.

Le changement le plus important auquel vous devrez faire attention apparaîtra quand vous tenterez de sous-classer les différents composants. La clé se trouve ci-dessous :

• Zend_Controller_Front::dispatch() intercepte par défaut les exceptions dans l'objet réponse, et ne les affiche pas, afin d'éviter l'affichage d'information sensible du système. Vous pouvez surcharger ceci de différentes manières :

  • Régler throwExceptions() dans le contrôleur frontal :

    1. $front->throwExceptions(true);

  • Régler renderExceptions() dans l'objet Réponse :

    1. $response->renderExceptions(true);
    2. $front->setResponse($response);
    3. $front->dispatch();
    4. // ou :
    5. $front->returnResponse(true);
    6. $response = $front->dispatch();
    7. $response->renderExceptions(true);
    8. echo $response;

• Zend_Controller_Dispatcher_Interface::dispatch() accepte maintenant et retourne un objet L'objet Requête au lieu d'un élément du distributeur.

• Zend_Controller_Router_Interface::route() accepte maintenant et retourne un objet L'objet Requête au lieu d'un élément du distributeur.

• Les changements de Zend_Controller_Action incluent :

  • Le constructeur accepte maintenant exactement trois arguments, Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, et le tableau facultatif $params. Zend_Controller_Action::__construct() les utilise pour affecter la requête, la réponse, et les propriétés invokeArgs de l'objet, et si vous devez surcharger le constructeur, vous devez faire de même. La meilleure solution est d'utiliser la méthode init() pour réaliser toute configuration de l'instance, puisque cette méthode est appelée en tant que action finale du constructeur.

  • run() n'est plus défini en tant qu'élément final, mais n'est pas non plus utilisé par le contrôleur frontal ; son seul but apparaît lors de l'utilisation de la classe en tant que contrôleur de page. Il prend maintenant deux arguments facultatifs, un Zend_Controller_Request_Abstract $request et un Zend_Controller_Response_Abstract $response.

  • indexAction() ne nécessite plus d'être défini, mais est recommandé en tant qu'action par défaut. Ceci permet lors de l'utilisation de RewriteRouter et des contrôleurs d'action de spécifier différentes méthodes d'action par défaut.

  • __call() peut être surchargé pour gérer automatiquement les actions non définies.

  • _redirect() prend maintenant un second paramètre facultatif, le code HTTP à retourner avec la redirection, et un troisième paramètre optionnel, $prependBase, qui peut indiquer que l'URL de base enregistré avec l'objet requête peut être ajouté en tant que suffixe à l'URL spécifié.

  • La propriété _action n'existe plus. Cette propriété était un Zend_Controller_Dispatcher_Token, qui n'existe plus maintenant. Le seul but de cet élément est de fournir l'information concernant le contrôleur, l'action et les paramètres d'URL de la requête. Cette information est maintenant disponible dans l'objet requête, et peut être interrogé comme ceci :

    1. // Récupère le nom de controleur de la requête
    2. // L'accès se fait via : $this->_action->getControllerName().
    3. // L'exemple ci-dessous utilise getRequest(), bien que vous pourriez
    4. // accéder directement à la propriété $_request ;
    5. // l'utilisation de getRequest() est recommandée puisque la classe
    6. // parente peut surcharger l'accès à l'objet requête.
    7. $controller = $this->getRequest()->getControllerName();
    8.  
    9. // Recupere le nom de l'action de la requete
    10. // L'acces se fait via : $this->_action->getActionName().
    11. $action = $this->getRequest()->getActionName();
    12.  
    13. // Recupere les parametres de la requete
    14. // Ceci n'a pas changé ; les méthodes _getParams() et _getParam()
    15. // relaient simplement l'objet requete maintenant.
    16. $params = $this->_getParams();
    17. $foo = $this->_getParam('foo', 'default');
    18. // parametre de la requete 'foo', en utilisant 'default'
    19. // en tant que valeur par défaut si aucune valeur n'est trouvée

  • noRouteAction() a été effacée. La manière appropriée de gérer les méthodes d'actions non-existantes est de les router vers une action par défaut en utilisant __call() :

    1. public function __call($method, $args)
    2. {
    3.     // Si la méthode requetee ne correspond a aucune methode 'Action',
    4.     // on renvoie vers la méthode d'action par défaut :
    5.     if ('Action' == substr($method, -6)) {
    6.         return $this->defaultAction();
    7.     }
    8.  
    9.     throw new Zend_Controller_Exception('Appel de methode invalide');
    10. }

• Zend_Controller_RewriteRouter::setRewriteBase() a été effacée. Utilisez plutôt Zend_Controller_Front::setBaseUrl() (ou Zend_Controller_Request_Http::setBaseUrl(), si vous utilisez cette classe de requête).

• Zend_Controller_Plugin_Interface a été remplacée par Zend_Controller_Plugin_Abstract. Toutes les méthodes acceptent et retournent maintenant un objet L'objet Requête au lieu d'un élément du distributeur.