repo_zf1Php7/documentation/manual/fr/module_specs/Zend_Controller-Migration.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: 15617 -->
<!-- Reviewed: no -->
<sect1 id="zend.controller.migration">
    <title>Migrer depuis des versions précédentes</title>

    <para>
        L'API des composants MVC a changé plusieurs fois. Si vous avez débuté avec des
        versions antérieures de Zend Framework, suivez les recommandations suivantes pour migrer
        vos scripts afin d'utiliser la nouvelle architecture.
    </para>

    <sect2 id="zend.controller.migration.fromoneseventooneeight">
        <title>Migrer de la version 1.7.x vers 1.8.0 ou plus récent</title>

        <sect3 id="zend.controller.migration.fromoneseventooneeight.router">
            <title>Changement de la route standard</title>

            <para>
                Comme les segments traduits ont été ajoutés dans la nouvelle route standard, le
                caractère <code>@</code> est maintenant un caractère spécial au début d'un segment
                de route. Pour être capable de l'utiliser dans un segment statique, vous devez
                l'échapper en le préfixant avec un second <code>@</code>. La même règle s'applique
                aussi au caractère <code>:</code>.
            </para>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromonesixtooneseven">
        <title>Migrer de la version 1.6.x vers 1.7.0 ou plus récent</title>

        <sect3 id="zend.controller.migration.fromonesixtooneseven.dispatcher">
            <title>Changement dans l'interface Dispatcher</title>

            <para>
                Les utilisateurs ont portés l'attention sur le fait que
                <classname>Zend_Controller_Action_Helper_ViewRenderer</classname> utilisait une
                méthode de la classe abstraite du distributeur standard qui n'était pas présente
                dans l'interface Dispatcher.La méthode suivante a donc été ajoutée pour s'assurer
                que les distributeurs personnalisés continueront à fonctionner avec les
                implémentations embarquées&#160;:
            </para>

            <itemizedlist>
                <listitem>
                    <para>
                        <code>formatModuleName()</code>&#160;: devrait être utilisé pour prendre
                        un nom de contrôleur brut, comme un qui aurait été embarqué dans un objet
                        requête, et pour le formater en un nom de classe approprié qu'une classe
                        étendant <classname>Zend_Controller_Action</classname> pourra
                        utiliser.
                    </para>
                </listitem>
            </itemizedlist>

        </sect3>

    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonesix">
        <title>Migrer de la version 1.5.x vers 1.6.0 ou plus récent</title>

        <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
            <title>Changement dans l'interface Dispatcher</title>

            <para>
                Les utilisateurs ont porté à notre connaissance le fait que
                <classname>Zend_Controller_Front</classname> et
                <classname>Zend_Controller_Router_Route_Module</classname> utilisent tous les deux
                des méthodes du distributeur qui ne sont pas dans l'interface associée. Nous avons
                donc ajouté les trois méthodes suivantes pour s'assurer que les distributeurs
                personnalisés continueront à fonctionner avec les implémentations embarquées&#160;:
            </para>

            <itemizedlist>
                <listitem>
                    <para>
                        <code>getDefaultModule()</code>&#160;: retourne le nom du module par
                        défaut.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        <code>getDefaultControllerName()</code>&#160;: retourne le nom du
                        contrôleur par défaut.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        <code>getDefaultAction()</code>&#160;: retourne le nom de l'action par
                        défaut.
                    </para>
                </listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonefive">
        <title>Migrer de la version 1.0.x vers 1.5.0 ou plus récent</title>

        <para>
            Bien que la plupart des fonctionnalités de base demeurent les mêmes, et que
            toutes les fonctionnalités documentées restent les mêmes, il existe une
            "fonctionnalité" particulière <emphasis>non documentée</emphasis> qui a changé.
        </para>

        <para>
            Quand vous écrivez des URLs, la manière documentée d'écrire les noms d'action en
            notationCamel est d'utiliser un séparateur de mot ; ceux ci sont "." ou "-" par défaut,
            mais ils peuvent être configurés dans le distributeur. Le distributeur en interne
            transforme les noms d'action en minuscules, et utilise ces séparateurs de mots pour
            ré-assembler la méthode d'action en utilisant la notationCamel. Cependant, comme les
            fonctions PHP ne sont pas sensibles à la casse, vous <emphasis>pouvez</emphasis>
            toujours écrire les URLs en utilisant la notationCamel, et le distributeur les résoudra
            de la même manière. Par exemple, "notation-camel" deviendra "notationCamelAction" dans
            le distributeur, tandis que "notationCamel" deviendra "notationcamelAction" ;
            cependant, à cause de l'insensibilité à la casse de PHP, dans les deux cas cela
            exécutera la même méthode.
        </para>

        <para>
            Ceci pose des problèmes avec le <code>ViewRenderer</code> lors de la résolution
            des scripts de vue. La manière canonique et documentée est que tous les séparateurs de
            mot sont convertis en tirets, et les mots en minuscules. Ceci crée un lien sémantique
            entre les actions et les scripts de vue, et la normalisation s'assure que les scripts
            peuvent être trouvés. Cependant, si l'action "notationCamel" est appelée et est
            résolue, le séparateur de mot n'est pas pour autant présent, et le
            <code>ViewRenderer</code> tente de résoudre un emplacement différent -
            "notationcamel.phtml" au lieu de "notation-camel.phtml".
        </para>

        <para>
            Quelques développeurs se sont fondés sur ce "dispositif", qui n'a jamais été
            prévu. Plusieurs changements de l'arbre 1.5.0, cependant, l'ont fait de sorte que le
            <code>ViewRenderer</code> ne résout plus ces chemins&#160;; le lien sémantique est
            maintenant imposé. A partir de maintenant, le distributeur impose la sensibilité à la
            casse dans les noms d'action. Ceci veut dire que la référence vers vos actions dans
            l'URL en utilisant la notationCamel ne résoudra plus les mêmes méthodes qu'en utilisant
            les séparateurs de mots (par ex., "notation-camel"). Ceci entraîne qu'à partir de
            maintenant le <code>ViewRenderer</code> honorera seulement les actions en
            "mots-séparés" lors de la résolution des scripts de vue.
        </para>

        <para>
            Si vous constatez que vous comptiez sur ce "dispositif", vous avez plusieurs
            options&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Meilleure option : renommez vos scripts de vue. Pour&#160;: compatibilité
                    ascendante. Contre&#160;: si vous avez beaucoup de scripts de vue basés sur
                    l'ancien, comportement fortuit, vous aurez beaucoup de renommage à
                    faire.
                </para>
            </listitem>
            <listitem>
                <para>
                    Seconde meilleure option&#160;: le <code>ViewRenderer</code> délégue
                    maintenant la résolution des scripts de vue à
                    <classname>Zend_Filter_Inflector</classname> ; vous pouvez modifier les règles
                    de l'inflecteur pour ne plus séparer les mots d'une action avec un tiret&#160;:
                </para>
                <programlisting language="php"><![CDATA[
$viewRenderer =
    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$inflector = $viewRenderer->getInflector();
$inflector->setFilterRule(':action', array(
    new Zend_Filter_PregReplace(
        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
        ''
    ),
    'StringToLower'
));
]]></programlisting>
                <para>
                    Le code ci-dessus modifiera l'inflecteur pour ne plus séparer les mots
                    avec un tiret&#160;; vous pouvez aussi vouloir supprimer le filtre
                    <code>StringToLower</code> si vous <emphasis>voulez</emphasis> que vos scripts
                    de vues utilisent aussi la notationCamel.
                </para>
                <para>
                    Si le renommage de vos scripts de vue est trop fastidieux ou nécessite
                    trop de temps, ceci est la meilleure option avant de trouver le temps de le
                    faire.
                </para>
            </listitem>
            <listitem>
                <para>
                    Option la moins souhaitable&#160;: vous pouvez forcer le distributeur à
                    distribuer les noms d'action écrits en notationCamel avec un nouveau drapeau du
                    contrôleur frontal, <code>useCaseSensitiveActions</code>&#160;:
                </para>
                <programlisting language="php"><![CDATA[
$front->setParam('useCaseSensitiveActions', true);
]]></programlisting>
                <para>
                    Ceci vous permettra d'utiliser la notationCamel dans l'URL et de toujours
                    faire résoudre la même action que si vous utilisez les séparateurs de mots.
                    Cependant, ceci signifiera que les problèmes décrits ci-dessus interviendront
                    tôt ou tard ; vous devrez probablement utiliser la deuxième option ci-dessus en
                    plus de celle-ci pour que tout fonctionne correctement.
                </para>
                <para>
                    Notez, de plus, que l'utilisation de ce drapeau déclenchera une
                    <code>notice</code> indiquant que cette utilisation est dépréciée.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninethree">
        <title>Migrer de la version 0.9.3 vers 1.0.0RC1 ou plus récent</title>

        <para>
            Les principaux changements introduits dans la version 1.0.0RC1 sont l'ajout et
            l'activation par défaut du plugin
            <link linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>et de
            l'aide d'action
            <link linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>.
            Veuillez lire la documentation de chacun des éléments directement pour apprendre leur
            fonctionnement et quels effets, ils peuvent avoir sur vos applications.
        </para>

        <para>
            Le plugin <code>ErrorHandler</code> est exécuté pendant
            <code>postDispatch()</code> 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 <code>noErrorHandler</code> du contrôleur frontal&#160;:
        </para>

        <programlisting language="php"><![CDATA[
$front->setParam('noErrorHandler', true);
]]></programlisting>

        <para>
            L'aide d'action <code>ViewRenderer</code> automatise l'injection de vues dans les
            contrôleurs d'action en tant 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
            <code>ViewRenderer</code> va tenter de rendre un script de vue basé sur le nom de
            l'action.
        </para>

        <para>
            Il existe plusieurs possibilités pour mettre à jour votre code. Dans un premier
            temps, vous pouvez globalement désactiver <code>ViewRenderer</code> dans votre fichier
            d'amorçage du contrôleur frontal avant toute distribution&#160;:
        </para>

        <programlisting language="php"><![CDATA[
// En considérant que $front est une instance de Zend_Controller_Front
$front->setParam('noViewRenderer', true);
]]></programlisting>

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

        <para>
            Quand vous serez prêt à utiliser la fonctionnalité <code>ViewRenderer</code>, 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&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>Appel de <code>$this-&gt;render()</code></para>
            </listitem>
            <listitem>
                <para>Appel de <code>$this-&gt;_forward()</code></para>
            </listitem>
            <listitem>
                <para>Appel de <code>$this-&gt;_redirect()</code></para>
            </listitem>
            <listitem>
                <para>Appel de l'aide d'action <code>Redirector</code></para>
            </listitem>
        </itemizedlist>

        <para>
            Le changement le plus simple est la désactivation de l'auto-rendu pour cette
            méthode&#160;:
        </para>

        <programlisting language="php"><![CDATA[
$this->_helper->viewRenderer->setNoRender();
]]></programlisting>

        <para>
            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
            <code>preDispatch()</code> ou <code>init()</code>&#160;:
        </para>

        <programlisting language="php"><![CDATA[
public function preDispatch()
{
    // désactive l'auto-rendu des scripts de vues
    $this->_helper->viewRenderer->setNoRender()
    // ... faire autre chose ...
}
]]></programlisting>

        <para>
            Si vous appelez <code>render()</code>, et que vous utilisez la
            <link linkend="zend.controller.modular">structure de dossier modulaire
            conventionnelle</link>, vous voudrez modifier votre code pour utiliser
            l'auto-rendu&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Si vous rendez de multiples scripts de vues dans une seule action, vous
                    n'avez rien à modifier.
                </para>
            </listitem>
            <listitem>
                <para>
                    Si vous appelez simplement <code>render()</code> sans aucun argument,
                    vous pouvez effacer ces lignes.
                </para>
            </listitem>
            <listitem>
                <para>
                    Si vous appelez <code>render()</code> avec des arguments, et que vous ne
                    réalisez pas ensuite d'exécution de code ou effectuez le rendu de scripts de
                    vues multiples, vous pouvez changer ces appels par
                    <code>$this->_helper->viewRenderer()</code>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Si vous n'utilisez pas la structure de dossier modulaire conventionnelle, il
            existe une variété de méthodes pour paramétrer le chemin de base des vues et les
            spécifications du chemin vers les scripts ainsi vous pourrez utiliser
            <code>ViewRenderer</code>. Veuillez lire la
            <link linkend="zend.controller.actionhelpers.viewrenderer">documentation de
            ViewRenderer</link>pour plus d'informations sur ces méthodes.
        </para>

        <para>
            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 <code>ViewRenderer</code> dans cet objet. Ceci peut être réalisé
            facilement à tout moment.
        </para>

        <itemizedlist>
            <listitem>
                <para>Avant la distribution d'une instance de contrôleur frontal&#160;:</para>
                <programlisting language="php"><![CDATA[
// 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);
]]></programlisting>
            </listitem>
            <listitem>
                <para>A tout moment durant le processus d'amorçage&#160;:</para>
                <programlisting language="php"><![CDATA[
$viewRenderer =
    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer->setView($view);
]]></programlisting>
            </listitem>
        </itemizedlist>

        <para>
            Il existe plusieurs manières de modifier <code>ViewRenderer</code>, 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 à <code>ViewRenderer</code>.
        </para>

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

    <sect2 id="zend.controller.migration.fromzeroninetwo">
        <title>Migrer de la version 0.9.2 vers 0.9.3 ou plus récent</title>

        <para>
            0.9.3 introduit les
            <link linkend="zend.controller.actionhelpers">aides d'actions</link>. En lien avec ce
            changement, les méthodes suivantes ont été effacées puisqu'elles sont maintenant
            encapsulées dans
            <link linkend="zend.controller.actionhelpers.redirector">l'aide d'action
            redirector</link>&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <code>setRedirectCode()</code> à remplacer par
                    <classname>Zend_Controller_Action_Helper_Redirector::setCode()</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectPrependBase()</code> à remplacer par
                    <classname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectExit()</code> à remplacer par
                    <classname>Zend_Controller_Action_Helper_Redirector::setExit()</classname>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Lisez la
            <link linkend="zend.controller.actionhelpers">documentation des aides
            d'actions</link>pour plus d'informations sur la récupération ou la manipulation des
            objets "helper", et la
            <link linkend="zend.controller.actionhelpers.redirector">documentation du helper
            redirector</link>pour plus d'informations sur le réglage des options de redirection (de
            même que pour les méthodes alternatives de redirection).
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerosix">
        <title>Migrer de la version 0.6.0 vers 0.8.0 ou plus récent</title>

        <para>
            Pour les versions précédentes, l'utilisation basique des composants MVC reste la
            même&#160;:
        </para>

        <programlisting language="php"><![CDATA[
Zend_Controller_Front::run('/chemin/vers/controleurs');
]]></programlisting>

        <para>
            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&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <classname>Zend_Controller_Router</classname> a été effacé en faveur du
                    routeur de réécriture ("rewrite router").
                </para>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_RewriteRouter</classname> a été renommé en
                    <classname>Zend_Controller_Router_Rewrite</classname>, et promu en tant que
                    routeur standard fourni avec le framework ;
                    <classname>Zend_Controller_Front</classname> l'utilise par défaut si aucun
                    autre routeur n'est fourni.
                </para>
            </listitem>
            <listitem>
                <para>
                    Une nouvelle classe de route à utiliser avec le routeur de réécriture a
                    été introduite, <classname>Zend_Controller_Router_Route_Module</classname> ;
                    elle couvre la route par défaut utilisée par le MVC, et supporte les
                    <link linkend="zend.controller.modular">modules de contrôleurs</link>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_Router_StaticRoute</classname> a été renommé
                    en <classname>Zend_Controller_Router_Route_Static</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_Dispatcher</classname> a été renommé en
                    <classname>Zend_Controller_Dispatcher_Standard</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    Les arguments de
                    <classname>Zend_Controller_Action::_forward()</classname> ont changés. La
                    signature est maintenant&#160;:
                </para>
                <programlisting language="php"><![CDATA[
final protected function _forward($action,
                                  $controller = null,
                                  $module = null,
                                  array $params = null);
]]></programlisting>
                <para>
                    <code>$action</code> est toujours obligatoire ; si aucun contrôleur n'est
                    spécifié, une action dans le contrôleur courant est considérée.
                    <code>$module</code> est toujours ignoré à moins que <code>$controller</code>
                    ne soit spécifié. Pour finir, tout <code>$params</code> 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 <code>null</code> pour ces
                    valeurs.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerotwo">
        <title>Migrer de la version 0.2.0 ou plus ancien vers 0.6.0</title>

        <para>
            L'utilisation de base des composants MVC n'a pas changé ; vous pouvez toujours
            faire comme suit&#160;:
        </para>

        <programlisting language="php"><![CDATA[
Zend_Controller_Front::run('/chemin/vers/controleurs');
]]></programlisting>

        <programlisting language="php"><![CDATA[
/* -- créer un routeur -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user', 'user/:username', array('controller' => 'user',
'action' => 'info'));

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

/* -- régler le répertoire des contrôleurs et distribuer -- */
$ctrl->setControllerDirectory('/chemin/vers/controleurs');
$ctrl->dispatch();
]]></programlisting>

        <para>
            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,
            <code>dispatch()</code> 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 <code>returnResponse()</code>, 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
            <ulink url="http://php.net/manual/fr/ref.outcontrol.php">bufferisation de
            sortie</ulink>.
        </para>

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

        <para>
            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&#160;:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <classname>Zend_Controller_Front::dispatch()</classname> 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&#160;:
                </para>
                <itemizedlist>
                    <listitem>
                        <para>
                            Régler <code>throwExceptions()</code> dans le contrôleur frontal&#160;:
                        </para>
                        <programlisting language="php"><![CDATA[
$front->throwExceptions(true);
]]></programlisting>
                    </listitem>
                    <listitem>
                        <para>
                            Régler <code>renderExceptions()</code> dans l'objet Réponse&#160;:
                        </para>
                        <programlisting language="php"><![CDATA[
$response->renderExceptions(true);
$front->setResponse($response);
$front->dispatch();
// ou :
$front->returnResponse(true);
$response = $front->dispatch();
$response->renderExceptions(true);
echo $response;
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_Dispatcher_Interface::dispatch()</classname>
                    accepte maintenant et retourne un objet
                    <xref linkend="zend.controller.request" /> au lieu d'un élément du
                    distributeur.
                </para>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_Router_Interface::route()</classname> accepte
                    maintenant et retourne un objet <xref linkend="zend.controller.request" /> au
                    lieu d'un élément du distributeur.
                </para>
            </listitem>
            <listitem>
                <para>
                    Les changements de <classname>Zend_Controller_Action</classname>
                    incluent&#160;:
                </para>
                <itemizedlist>
                    <listitem>
                        <para>
                            Le constructeur accepte maintenant exactement trois arguments,
                            <classname>Zend_Controller_Request_Abstract $request</classname>,
                            <classname>Zend_Controller_Response_Abstract $response</classname>, et
                            le tableau facultatif <code>$params</code>.
                            <classname>Zend_Controller_Action::__construct()</classname> les
                            utilise pour affecter la requête, la réponse, et les propriétés
                            <code>invokeArgs</code> 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 <code>init()</code> pour réaliser toute
                            configuration de l'instance, puisque cette méthode est appelée en tant
                            que action finale du constructeur.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            <code>run()</code> 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
                            <classname>Zend_Controller_Request_Abstract $request</classname> et un
                            <classname>Zend_Controller_Response_Abstract
                            $response</classname>.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            <code>indexAction()</code> 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 <code>RewriteRouter</code> et des contrôleurs d'action
                            de spécifier différentes méthodes d'action par défaut.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            <code>__call()</code> peut être surchargé pour gérer
                            automatiquement les actions non définies.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            <code>_redirect()</code> prend maintenant un second paramètre
                            facultatif, le code HTTP à retourner avec la redirection, et un
                            troisième paramètre optionnel, <code>$prependBase</code>, 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é.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            La propriété <code>_action</code> n'existe plus. Cette propriété
                            était un <classname>Zend_Controller_Dispatcher_Token</classname>, 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&#160;:
                        </para>
                        <programlisting language="php"><![CDATA[
// Récupère le nom de controleur de la requête
// L'accès 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 puisque 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 méthodes _getParams() et _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
]]></programlisting>
                    </listitem>
                    <listitem>
                        <para>
                            <code>noRouteAction()</code> 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 <code>__call()</code>&#160;:
                        </para>
                        <programlisting language="php"><![CDATA[
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');
}
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_RewriteRouter::setRewriteBase()</classname> a
                    été effacée. Utilisez plutôt
                    <classname>Zend_Controller_Front::setBaseUrl()</classname> (ou
                    Zend_Controller_Request_Http::setBaseUrl(), si vous utilisez cette classe de
                    requête).
                </para>
            </listitem>
            <listitem>
                <para>
                    <classname>Zend_Controller_Plugin_Interface</classname> a été remplacée
                    par <classname>Zend_Controller_Plugin_Abstract</classname>. Toutes les méthodes
                    acceptent et retournent maintenant un objet
                    <xref linkend="zend.controller.request" /> au lieu d'un élément du
                    distributeur.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>
</sect1>