Les principaux changements introduits dans la version 1.0.0RC1 sont l'ajout et l'activation par défaut du plugin ErrorHandler et de l'aide d'action ViewRenderer. Veuillez lire la documentation de chacun des éléments directement pour apprendre leur fonctionnement et quels effets, ils peuvent avoir sur vos applications.

Le plugin ErrorHandler est éxécuté pendant postDispatch() vérifiant la présence d'exceptions, et redirigeant vers le contrôleur de gestion d'erreur spécifié. Vous pouvez le désactiver en réglant le paramètre noErrorHandler du contrôleur frontal :

<?php
$front->setParam('noErrorHandler', true);
        

L'aide d'action ViewRenderer automatise l'injection de vuesdans les contrôleurs d'action en tant que qu'autogénération des scripts de vues suivant l'action courante. Le principal problème que vous pourriez rencontrer intervient quand vous avez des actions qui ne rendent pas de scripts de vues ni ne font suivre ou redirige, alors ViewRenderer va tenter de rendre un script de vue basé sur le nom de l'action.

Il existe plusieurs possibilités pour mettre à jour votre code. Dans un premier temps, vous pouvez globalement désactiver ViewRenderer dans votre fichier d'amorçage du contrôleur frontal avant tout dispatchage :

<?php
// En considérant que $front est une instance de Zend_Controller_Front
$front->setParam('noViewRenderer', true);
        

Cependant, ceci n'est pas une bonne stratégie à long terme, car il apparaît aisément que vous devrez écrire plus de code.

Quand vous serez prêt à utiliser la fonctionnalité ViewRenderer, il y a plusieurs choses à vérifier dans votre code de contrôleur. Premièrement, regardez vos méthodes d'actions (les méthodes se terminant par "Action"), et déterminez ce que chacune d'elle réalise. Si rien de ce qui suit n'est réalisé, vous devrez réaliser des changements :

• Appel de $this->render()

• Appel de $this->_forward()

• Appel de $this->_redirect()

• Appel de l'aide d'action Redirector

Le changement le plus simple est la désactivation de l'auto-rendu pour cette méthode :

$this->_helper->viewRenderer->setNoRender();
        

Si vous trouvez qu'aucune de vos méthodes d'actions n'effectue de rendu, ne font suivre, ou redirige, vous pouvez préférer mettre la ligne suivante dans la méthode preDispatch() ou init() :

public function preDispatch()
{
    // désactive l'auto-rendu des scripts de vues
    $this->_helper->viewRenderer->setNoRender()
    // ... faire autre chose ...
}
        

Si vous appelez render(), et que vous utilisez la structure de dossier modulaire conventionnelle, vous voudrez modifier votre code pour utiliser l'auto-rendu :

• Si vous rendez de multiples scripts de vues dans une seule action, vous n'avez rien à modifier.

• Si vous appelez simplement render() sans aucun argument, vous pouvez effacer ces lignes.

• Si vous appelez render() avec des arguments, et que vous ne réalisez pas ensuite d'éxécution de code ou effectuez le rendu de scripts de vues multiples, vous pouvez changer ces appels par $this->_helper->viewRenderer().

Sivous n'utilisez pas la structure de dossier modulaire conventionnelle, il existe une variété de méthodes pour régler le chemin de base des vues et les spécifications du chemin vers les scripts ainsi vous pourrez utiliser ViewRenderer. Veuillez lire la documentation de ViewRenderer pour plus d'informations sur ces méthodes.

Si vous utilisez un objet de vue issu du registre, ou que vous personnalisez votre objet vue, ou que vous utilisez une implémentation de vue différente, vous pouvez vouloir injecter ViewRenderer dans cet objet. Ceci peut être réalisé facilement à tout moment.

• Avant le dispatchage d'une instance de contrôleur frontal :

  <?php
  // En considérant que $view a déjà été définie
  $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
  Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
                  

• A tout moment durant le processus d'amorçage :

  <?php
  $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
  $viewRenderer->setView($view);
                  

Il existe plusieurs manières de modifier ViewRenderer, incluant le réglage d'un script de vue différent à rendre, la spécification d'un remplaçant pour tous les éléments remplaçables d'un chemin de script de vues (incluant le suffixe), le choix d'un segment nommé de la réponse à utiliser, et plus encore. Si vous n'utilisez pas la structure de dossier modulaire conventionnelle, vous pouvez tout de même associer différentes spécifications de chemin à ViewRenderer.

Nous vous encourageons à adapter votre code pour utiliser ErrorHandler et ViewRenderer puisqu'il s'agit maintenant de fonctionnalités natives.

0.9.3 introduit les aides d'actions. En lien avec ce changement, les méthodes suivantes ont été éffacées puisqu'elles sont maintenant encapsulées dans l'aide d'action redirector :

• setRedirectCode() à remplacer par Zend_Controller_Action_Helper_Redirector::setCode().

• setRedirectPrependBase() à remplacer par Zend_Controller_Action_Helper_Redirector::setPrependBase().

• setRedirectExit() à remplacer par Zend_Controller_Action_Helper_Redirector::setExit().

Lisez la documentation des aides d'actions pour plus d'informations sur la récupération ou la manipulation des objets helper, et la documentation du helper redirector pour plus d'informations sur le réglage des options de redirection (de même que pour les méthodes alternatives de redirection).

Pour les versions précédentes, l'utilisation basique des composants MVC reste la même :

require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/chemin/vers/controleurs');
        

Cependant, la structure des dossiers a subi une réorganisation, certains composants ont été effacés, et d'autres ont été soit renommés soit ajoutés. Les changements incluent :

• Zend_Controller_Router a été effacé en faveur du routeur de réécriture (rewrite router).

• Zend_Controller_RewriteRouter a été renommé en Zend_Controller_Router_Rewrite, et promu en tant que routeur standard fourni avec le framework ; Zend_Controller_Front l'utilise par défaut si aucun autre routeur n'est fourni.

• Une nouvelle classe de route à utiliser avec le routeur de réécriture a été introduite, Zend_Controller_Router_Route_Module ; elle couvre la route par défaut utilisée par le MVC, et supporte les modules de contrôleurs.

• Zend_Controller_Router_StaticRoute a été renommé en Zend_Controller_Router_Route_Static.

• Zend_Controller_Dispatcher a été renommé en Zend_Controller_Dispatcher_Standard.

• Les arguments de Zend_Controller_Action::_forward() ont changés. La signature est maintenant :

  final protected function _forward($action, $controller = null, $module = null, array $params = null);
                  

  $action est toujours obligatoire ; si aucun contrôleur n'est spécifié, une action dans le contrôleur courant est considérée. $module est toujours ignoré à moins que $controller ne soit spécifié. Pour finir, tout $params fourni sera ajouté à l'objet requête. Si aucun contrôleur ou module n'est nécessaire, mais que des paramètres le sont, passez simplement null pour ces valeurs.

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

require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/chemin/vers/controleurs');
        

/* -- creer un routeur -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user', 'user/:username', array('controller' => 'user',
'action' => 'info'));

/* -- l'affecter à un controleur -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- regler le repertoire des controleurs et dispatcher -- */
$ctrl->setControllerDirectory('/chemin/vers/controleurs');
$ctrl->dispatch();
        

Nous encourageons l'utilisation de l'objet Réponse pour aggréger le contenu et les entê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 entê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 :

    $front->throwExceptions(true);
                            

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

    $response->renderExceptions(true);
    $front->setResponse($response);
    $front->dispatch();
    
    // ou :
    $front->returnResponse(true);
    $response = $front->dispatch();
    $response->renderExceptions(true);
    echo $response;
                            

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

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

• 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 as non plus utilisé par le contrôler 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ée 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 optionel, $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 :

    // Recupere le nom de controleur de la requete
    // L'acces se fait via : $this->_action->getControllerName().
    // L'exemple ci-dessous utilise getRequest(), bien que vous pourriez accéder directement
    // à la propriété $_request ; l'utilisation de getRequest() est recommandée puisue la classe
    // parente peut surcharger l'accès à l'objet requête.
    $controller = $this->getRequest()->getControllerName();
    
    // Recupere le nom de l'action de la requete
    // L'acces se fait via : $this->_action->getActionName().
    $action = $this->getRequest()->getActionName();
    
    // Recupere les parametres de la requete
    // Ceci n'a pas changé ; les methodes _getParams() and _getParam() relaient simplement
    // l'objet requete maintenant.
    $params = $this->_getParams();
    $foo = $this->_getParam('foo', 'default'); // parametre de la requete 'foo', en utilisant
                                               // 'default' en tant que valeur par défaut si aucune valeur n'est trouvée
                            

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

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

• Zend_Controller_RewriteRouter::setRewriteBase() a été effacé. 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é 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 dispatcheur.