| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239 |
- <?xml version="1.0" encoding="UTF-8"?>
- <!-- EN-Revision: 24249 -->
- <!-- Reviewed: no -->
- <sect1 id="migration.06">
- <title>Zend Framework 0.6</title>
- <para>
- Lors de la migration d'un version précédente vers Zend Framework 0.6 ou plus récent
- vous devriez prendre note de ce qui suit.
- </para>
- <sect2 id="migration.06.zend.controller">
- <title>Zend_Controller</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>
|