|
|
@@ -1,740 +0,0 @@
|
|
|
-<?xml version="1.0" encoding="utf-8"?>
|
|
|
-<!-- EN-Revision: 17171 -->
|
|
|
-<!-- Reviewed: no -->
|
|
|
-<sect1 id="zend.controller.migration">
|
|
|
- <title>Migrer depuis des versions précédentes</title>
|
|
|
-
|
|
|
- <para>
|
|
|
- L'API des composants <acronym>MVC</acronym> 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 :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>formatModuleName()</methodname> : 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 :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>getDefaultModule()</methodname> : retourne le nom du module par
|
|
|
- défaut.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>getDefaultControllerName()</methodname> : retourne le nom du
|
|
|
- contrôleur par défaut.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>getDefaultAction()</methodname> : 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 <acronym>URL</acronym>s, 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 <acronym>PHP</acronym> ne sont pas sensibles à la casse, vous <emphasis>pouvez</emphasis>
|
|
|
- toujours écrire les <acronym>URL</acronym>s 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 <acronym>PHP</acronym>, 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 ; 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 :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- Meilleure option : renommez vos scripts de vue. Pour : compatibilité
|
|
|
- ascendante. Contre : 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 : 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 :
|
|
|
- </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 ; 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 : vous pouvez forcer le distributeur à
|
|
|
- distribuer les noms d'action écrits en notationCamel avec un nouveau drapeau du
|
|
|
- contrôleur frontal, <code>useCaseSensitiveActions</code> :
|
|
|
- </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
|
|
|
- <methodname>postDispatch()</methodname> 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 :
|
|
|
- </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 :
|
|
|
- </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 :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>Appel de <code>$this->render()</code></para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>Appel de <code>$this->_forward()</code></para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>Appel de <code>$this->_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 :
|
|
|
- </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
|
|
|
- <methodname>preDispatch()</methodname> ou <methodname>init()</methodname> :
|
|
|
- </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 <methodname>render()</methodname>, 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 :
|
|
|
- </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 <methodname>render()</methodname> sans aucun argument,
|
|
|
- vous pouvez effacer ces lignes.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- Si vous appelez <methodname>render()</methodname> 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 :</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 :</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> :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>setRedirectCode()</methodname> à remplacer par
|
|
|
- <methodname>Zend_Controller_Action_Helper_Redirector::setCode()</methodname>.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>setRedirectPrependBase()</methodname> à remplacer par
|
|
|
- <methodname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</methodname>.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>setRedirectExit()</methodname> à remplacer par
|
|
|
- <methodname>Zend_Controller_Action_Helper_Redirector::setExit()</methodname>.
|
|
|
- </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 <acronym>MVC</acronym> reste la
|
|
|
- même :
|
|
|
- </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 :
|
|
|
- </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 <acronym>MVC</acronym>, 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
|
|
|
- <methodname>Zend_Controller_Action::_forward()</methodname> ont changés. La
|
|
|
- signature est maintenant :
|
|
|
- </para>
|
|
|
- <programlisting language="php"><![CDATA[
|
|
|
-final protected function _forward($action,
|
|
|
- $controller = null,
|
|
|
- $module = null,
|
|
|
- array $params = null);
|
|
|
-]]></programlisting>
|
|
|
- <para>
|
|
|
- <varname>$action</varname> est toujours obligatoire ; si aucun contrôleur n'est
|
|
|
- spécifié, une action dans le contrôleur courant est considérée.
|
|
|
- <varname>$module</varname> est toujours ignoré à moins que <varname>$controller</varname>
|
|
|
- ne soit spécifié. Pour finir, tout <varname>$params</varname> 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 <constant>NULL</constant> 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 <acronym>MVC</acronym> n'a pas changé ; vous pouvez toujours
|
|
|
- faire comme suit :
|
|
|
- </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, <acronym>JSON</acronym> ou <acronym>XML</acronym> au lieu de <acronym>XHTML</acronym>) dans vos applications. Par défaut,
|
|
|
- <methodname>dispatch()</methodname> 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 <methodname>returnResponse()</methodname>, 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 :
|
|
|
- </para>
|
|
|
-
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>Zend_Controller_Front::dispatch()</methodname> 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 :
|
|
|
- </para>
|
|
|
- <itemizedlist>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- Régler <methodname>throwExceptions()</methodname> dans le contrôleur frontal :
|
|
|
- </para>
|
|
|
- <programlisting language="php"><![CDATA[
|
|
|
-$front->throwExceptions(true);
|
|
|
-]]></programlisting>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- Régler <methodname>renderExceptions()</methodname> dans l'objet Réponse :
|
|
|
- </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>
|
|
|
- <methodname>Zend_Controller_Dispatcher_Interface::dispatch()</methodname>
|
|
|
- accepte maintenant et retourne un objet
|
|
|
- <xref linkend="zend.controller.request" /> au lieu d'un élément du
|
|
|
- distributeur.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>Zend_Controller_Router_Interface::route()</methodname> 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 :
|
|
|
- </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 <varname>$params</varname>.
|
|
|
- <methodname>Zend_Controller_Action::__construct()</methodname> 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 <methodname>init()</methodname> 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>
|
|
|
- <methodname>run()</methodname> 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>
|
|
|
- <methodname>indexAction()</methodname> 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>
|
|
|
- <methodname>__call()</methodname> peut être surchargé pour gérer
|
|
|
- automatiquement les actions non définies.
|
|
|
- </para>
|
|
|
- </listitem>
|
|
|
- <listitem>
|
|
|
- <para>
|
|
|
- <methodname>_redirect()</methodname> prend maintenant un second paramètre
|
|
|
- facultatif, le code <acronym>HTTP</acronym> à retourner avec la redirection, et un
|
|
|
- troisième paramètre optionnel, <varname>$prependBase</varname>, 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 :
|
|
|
- </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>
|
|
|
- <methodname>noRouteAction()</methodname> 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 <methodname>__call()</methodname> :
|
|
|
- </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>
|
|
|
- <methodname>Zend_Controller_RewriteRouter::setRewriteBase()</methodname> a
|
|
|
- été effacée. Utilisez plutôt
|
|
|
- <methodname>Zend_Controller_Front::setBaseUrl()</methodname> (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>
|
mikaelkael