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

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.controller.migration">
    <title>Migración de versiones anteriores</title>

    <para>
    	La API de los componentes de MVC  ha cambiado en el tiempo. Si usted ha empezado a
    	usar una versión anterior de Zend Framework, siga la guía de abajo para
    	migrar sus acripts para usar la arquitectura nueva.
    </para>

	<sect2 id="zend.controller.migration.fromoneseventooneeight">
		<title>Migración de 1.7.x a 1.8.0 o nuevas versiones</title>

		<sect3 id="zend.controller.migration.fromoneseventooneeight.router">
			<title>Cambios en Standard Route </title>

			<para>
				Como los segmentos traducidos fueron presentados en la nueva
				standard
				route, El caracter
				<code>@</code>
				es ahora un carácter especial al principio de
				un segmento del route. Para poder utilizarlo en un segmento estático,
				tiene que escaparlo usando un segundo caracater
				<code>@</code>
				como prefijo. La misma regla se aplica ahora para el
				caracter
				<code>:</code>
				.
			</para>
		</sect3>
	</sect2>

    
    <sect2 id="zend.controller.migration.fromonesixtooneseven">
        <title>Migración de 1.6.x a 1.7.0 o nuevas versiones</title>

        <sect3 id="zend.controller.migration.fromonesixtooneseven.dispatcher">
            <title>Cambios en la interfaz del Dispatcher</title>

            <para>
				Los usuarios llamaron nuestra atención el hecho de que
                <classname> Zend_Controller_Action_Helper_ViewRenderer </classname> estaba
                utilizando un método Dispatcher de la clase abstracta que no está en
                el Dispatcher de la interfaz. Hemos añadido el siguiente método para
                garantizar que los Dispatcher de costumbre seguirán trabajando con las
                implementaciones enviadas:
            </para>

            <itemizedlist>
            	<listitem><para>
                    <code>formatModuleName()</code>: debe utilizarse para tomar un nuevo
                nombre de controlador, tal como uno que debería estar basado dentro de una petición
                objeto, y cambiarlo a un nombre de clase apropiado que la clase extendida
                <classname>Zend_Controller_Action</classname> debería usar
                </para></listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonesix">
        <title>Migrando desde 1.5.x to 1.6.0 o versiones posteriores</title>

        <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
            <title>Cambios en la interfaz del Dispatcher</title>

            <para>            		
				Los usuarios atrajeron nuestra atención con el hecho de que
                 <classname> Zend_Controller_Front </classname> y
                 <classname> Zend_Controller_Router_Route_Module </classname> fueron
                 utilizando métodos del despachador que no estaban en la interfaz del
                 despachador. Ahora hemos adicionado los siguientes tres métodos para
                 asegurar que los despachadores diseñados sigan trabajando con las
                 implementaciones enviadas:
            </para>

            <itemizedlist>
                <listitem><para>
                    <code>getDefaultModule()</code>: debe retornar el nombre del
                    módulo por defecto.
                </para></listitem>

                <listitem><para>
                    <code>getDefaultControllerName()</code>: debe retornar el
                    nombre del controlador por defecto.
                </para></listitem>

                <listitem><para>
                    <code>getDefaultAction()</code>: debe retornar el
                    nombre de la acción por defecto.
                </para></listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonefive">
        <title>Migranado desde 1.0.x a 1.5.0 o versiones posteriores</title>

        <para>        		
			Aunque la mayoría de la funcionalidad básica sigue siendo la misma, y todas las
			funcionalidades documentadas siguen siendo la mismas, hay una en particular
            "característica" <emphasis>undocumented</emphasis> que ha cambiado.
        </para>

        <para>        		
			Al escribir las URLs, la manera de escribir la documentada acción camelCased
            es usar un separador de palabra, que son "." o '-' por defecto,
            pero pueden ser configurados en el despachador. El despachador internamente
            convierte en minúsculas el nombre de la acción, y usa estos separadores de palabra para
            volver a montar el método de la acción camelCasing. Sin embargo, debido a que las
            funciones de PHP no son sensibles a mayúsculas y minúsculas, usted <emphasis>podría</emphasis>
            escribir las URLs usando camelCasing, y el despachador los devolvería
            a la misma ubicación. Por ejemplo, 'camel-cased' se convertirá en
            'camelCasedAction' por el despachador, mientras que 'camelCased' se
            convertiría en 'camelCasedAction'; sin embargo, debido a la insensibilidad de
            PHP, ambos ejecutarán el mismo método.
        </para>

        <para>        	
			Esto causa problemas con la vista ViewRenderer cuando devuelve scripts de la
			vista. El canónico, la documentada forma es que todos los separadores de palabra
            se conviertan en guiones, y las palabras en minúsculas. Esto crea
            un lazo semántico entre las acciones y los scripts de las vistas, y la
            normalización asegura que los scripts puedan ser encontrados. Sin embargo, si la
            acción "camelCased' es llamada y de hecho retornada, el separador de la palabra
            no está mas presente, y los ViewRenderer intenta devolver
            a una ubicación diferente -- 'camelcased.phtml' en vez de
            'camel-cased.phtml'.
        </para>

        <para>
        	Algunos desarrolladores se basarón en esta "característica", que nunca fue la intención.
            Varios cambios en el árbol 1.5.0 , sin embargo, hizo que la vista
            ViewRenderer ya no resuelva estas direcciones, la semántica esta ahora
            forzada. La primera de ellas, el despachador ahora impone
            la sensibilidad en los nombres de la acción. Lo que esto significa es que la referencia a
            sus acciones en la url utilisando camelCasing ya no para devolver
            al mismo método que utilizan los separadores de palabras (es decir, 'camel-casing').
            Esto nos lleva a la vista ViewRenderer ahora sólo en honor a las acciones
            palabra-separador cuando se devuleven los scripts vista.
        </para>

        <para>
            Si usted nota que estaba dependiendo en esta "caracteristica", usted tiene muchas
            opciones:
        </para>

        <itemizedlist>
            <listitem><para>
            		Mejor opción: cambiar el nombre de sus scripts de la vistas. Pros:
                    compatibilidad hacia adelante. Contras: si usted tiene muchos scripts vista que
                    se basan en la primera vista, una conducta no deseada, tendrá
                    mucho por hacer.
            </para></listitem>

            <listitem>
                <para>                	
					Segunda mejor opción: La vista ViewRenderer delega ahora resoluciones de scripts
					de vistas a <classname> Zend_Filter_Inflector </classname>; se puede
                    modificar las normas del inflector para que ya no separe
                    las palabras de una acción con un guión:
                </para>

                <programlisting role="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>                		
					El anterior código modificará el inflector para que ya no
                    separe las palabras con guión, usted puede querer eliminar
                    el filtro 'StringToLower' si usted desea<emphasis>hacer</emphasis>
                    el nombre de script de vista actual camelCased también.
                </para>

                <para>
					Si cambiar el nombre del script vista sería demasiado tedioso o tiempo
                    consumido, esta es su mejor opción hasta que pueda encontrar el
                    tiempo para hacerlo.
                </para>
            </listitem>

            <listitem>
                <para>
                	La opción menos deseable: Usted puede forzar al despachador para
                	despachar nombres de acción camelCased con un nuevo controlador
                    bandera, 'useCaseSensitiveActions':
                </para>

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

                <para>
					Esto le permitirá utilizar camelCasing sobre la url y siguir
                    tieniendo resuelta la misma acción como cuando se utilizaba los separadores
                    de palabra. Sin embargo, esto significa que los problemas originales
                    se iran terminando, lo más probable es utilizar la
                    segunda opción anterior, además de esto para que las cosas funcionen
                    confiablemente en todo.
                </para>

                <para>
                	Note, también, el uso de esta bandera aumentará un aviso de que
                	este uso es obsoleto.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninethree">
        <title>Migrando desde 0.9.3 a 1.0.0RC1 o versiones posteriores</title>

        <para>
        	Los cambios principales introducidos en 1.0.0RC1 son la introducción de
        	y la activación por defecto del plugin
			<link
                linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
        	y de acción ayuda <link
                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>
            Por favor, lea la documentación de cada uno completamente para ver
            cómo funcionan y qué efecto pueden tener en sus
            aplicaciones.
        </para>

        <para>
        	El plugin <code>ErrorHandler</code> corre durante
            <code>postDispatch ()</code> para el control de excepciones, y enviarlo
            a un especifico controlador de errores. Usted debe incluir tal
            controlador en su aplicación. Usted puede desactivarlo determinando el
            parámetro del controlador <code> noErrorHandler </code>:
        </para>

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

        <para>
			La acción de ayuda <code>ViewRenderer</code> automatiza inyección de vistas
            en controladores de acción así como los autogeneradores de scripts de vistas
            basados en la acción actual. El principal problema que se puede encontrar es
            si se tiene acciones que no generan scripts de vista y tampoco llevan
            o redireccionan, como <code>ViewRenderer</code> intentará generar
            un scrip de vista basado en el nombre de la acción.
        </para>

        <para>
        	Existen varias estrategias que se puede tomar para actualizar su código. En
            el corto plazo, se puede deshabilitar globalmente 
            <code> ViewRenderer </code> en su controlador frontal bootstrap antes del
            despache:
        </para>

        <programlisting role="php"><![CDATA[
// Asumiendo que $front es una instacia de Zend_Controller_Front
$front->setParam('noViewRenderer', true);
]]></programlisting>

        <para>
        	Sin embargo, esta no es una buena estrategia a largo plazo, eso significa que es
        	probable que usted escriba mas código.
        </para>

        <para>
        	Cuando se esta listo para empezar a usar la funcionalidad
        	<code>ViewRenderer</code>, existen demasiadas cosas que ver en el
        	código del controlador. Primero, ver las acciones método (los métodos
        	terminados en 'Action'), y determinar lo que cada uno esta haciendo. Si ninguno
        	de los siguientes esta pasando, usted necesitará hacer cambios:        	
        </para>

        <itemizedlist>
            <listitem><para>Llamar a <code>$this-&gt;render()</code></para></listitem>
            <listitem><para>Llamar a <code>$this-&gt;_forward()</code></para></listitem>
            <listitem><para>Llamar a <code>$this-&gt;_redirect()</code></para></listitem>
            <listitem><para>Llamar a el <code>Redirector</code> action helper</para></listitem>
        </itemizedlist>

        <para>
        	La forma mas fácil de cambiar es deshabilitar auto-rendering para ese método:
        </para>

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

        <para>
        	Si se encuentra que ninguno de sus acciones método se estan enviando,
            transmitiendo, o redireccionando, lo más probable es que se quiera poner encima de la
            línea en su <code> preDispatch () </code> o <code> de init() </code>
            métodos:
        </para>

        <programlisting role="php"><![CDATA[
public function preDispatch()
{
    // disable view script autorendering
    $this->_helper->viewRenderer->setNoRender()
    // .. do other things...
}
]]></programlisting>

        <para>
        	Si se está llamando a <code>render()</code>, y si está usando <link
                linkend="zend.controller.modular"> la Convención Modular
                de estructura de directorios</link>, usted preferirá cambiar su código a 
            hacer uso del auto envio:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                	Si se esta enviando scripts de vistas multiples en una sóla
                	acción, usted no necesoita cambiar nada.
                </para>
            </listitem>
            <listitem>
                <para>
                	Si se está simplemente llamando <code>render()</code> sin ningún
                	argumento, se puede remover tales líneas.
                </para>
            </listitem>
            <listitem>
                <para>
                	Si se está llamando con argumentos, y
                	no se esta haciendo ningún proceso después or enviando 
                	scrips de vistas multiples, se puede cambiar estas llamadas a leer
                    <code>$this-&gt;_helper-&gt;viewRenderer()</code>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
        	Si no se esta usando la convención modular de estructura de directorios,
        	existen variedad de métodos para definir la dirección de la vista base y
        	scripts de especificaciones de dirección así se puede hacer uso de 
            <code>ViewRenderer</code>. Pro favor leer la docuemntación de<link
                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer
                </link> para información de esos métodos.
        </para>

        <para>
        	Si se esta usando un objeto vista desde el registro o personalizando su 
        	objeto vista o usando una diferente implementación de vista, se deseará
        	introducir <code>ViewRenderer</code> con este objeto. Esto puede ser
        	terminado facilmente en cualquier momento.
        </para>

        <itemizedlist>
            <listitem>
                <para>
                	Antes de despachar una instancia del controlador frontal:
                </para>

                <programlisting role="php"><![CDATA[
// Asumiendo que $view ha sido definido
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
]]></programlisting>
            </listitem>

            <listitem>
                <para>
                	Cualquier momento el processo bootstrap:
                </para>

                <programlisting role="php"><![CDATA[
$viewRenderer =
    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer->setView($view);
]]></programlisting>
            </listitem>
        </itemizedlist>

        <para>
        	Existen muchas vias para modificar <code>ViewRenderer</code>,
        	incluyendo la definición de diferentes scripts de vista a enviar, especificando 
        	reemplazantes para todos los elementos reemplazables de la dirección del script vista
        	(incluyendo el sufijo), eligiendo una respuesta nombrada segmento para 
        	utilizar y mas. Si no esta usando la convención modular de 
        	estructura de directorios, se puede asociar diferentes especificaciones 
        	de direcciones con <code>ViewRenderer</code>.
        </para>

        <para>
			Le animamos a adaptar el código para utilizar el
            <code>ErrorHandler</code> y <code>ViewRenderer</code>, ya que son
            ahora funcionalidad básica.
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninetwo">
        <title>Migrando desde 0.9.2 to 0.9.3 o nuevas versiones</title>

        <para>
            0.9.3 introduce <link
                linkend="zend.controller.actionhelpers">action helpers</link>.
            Como parte de este cambio, los siguientes métodos han sido removidos ya
            que ahora son encapsulados en <link
                linkend="zend.controller.actionhelpers.redirector">redirector
                action helper</link>:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <code>setRedirectCode()</code>; usa
                    <classname>Zend_Controller_Action_Helper_Redirector::setCode()</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectPrependBase()</code>; usa
                    <classname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</classname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectExit()</code>; usa
                    <classname>Zend_Controller_Action_Helper_Redirector::setExit()</classname>.
                </para>
            </listitem>
        </itemizedlist>

        <para>        		
			Leer la documentación <link linkend="zend.controller.actionhelpers">ayudantes 
				de acción</link> para obtener más información sobre cómo
             recuperar y manipular objetos de ayuda, y la <link
                 linkend = "zend.controller.actionhelpers.redirector"> documentación
                 del ayudante redirector</link> para obtener más información sobre la configuración
             de reorientar las opciones (así como los alternativos métodos para la redirección).             
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerosix">
        <title>Migrando desde 0.6.0 to 0.8.0 o versiones nuevas</title>

        <para>
        	Por los cambios previos, el más básico uso de los componentes MVC 
            sigue siendo el mismo:
        </para>

        <programlisting role="php"><![CDATA[
Zend_Controller_Front::run('/path/to/controllers');
]]></programlisting>

        <para>      
			Sin embargo, la estructura de directorios se sometió a una revisión, varios
            componentes han sido eliminados, y varios otros ya sea añadidos o adicionados.
            Los cambios incluyen:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <classname>Zend_Controller_Router</classname> fue eliminado en favor de 
                    reescribir el router.
                </para>
            </listitem>

            <listitem>
                <para>                		
					<classname> Zend_Controller_RewriteRouter </classname> ha sido renombrado a
                    <classname> Zend_Controller_Router_Rewrite </classname>, y promovido a 
                    router estándar enviado con el framework;
                    <classname> Zend_Controller_Front </classname> lo utilizará por defecto si
                    ningún otro router es sustituido.
                </para>
            </listitem>

            <listitem>
                <para>                		
					Una nueva clase ruta para uso con el router reescribir se 
                    presentó,
                    <classname> Zend_Controller_Router_Route_Module </classname>, que abarca
                    la ruta por defecto utilizado por el MVC, y tiene soporte para el<link
                    	linkend = "zend.controller.modular">controlador de
                        módulos </link>.
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_Router_StaticRoute</classname> was renamed
                    to <classname>Zend_Controller_Router_Route_Static</classname>.
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_Dispatcher</classname> was renamed
                    <classname>Zend_Controller_Dispatcher_Standard</classname>.
                </para>
            </listitem>

            <listitem>
                <para>
                    Los argumentos de <classname>Zend_Controller_Action::_forward()</classname>
                    han cambiado. la firma es ahora:
                </para>

                <programlisting role="php"><![CDATA[
final protected function _forward($action,
                                  $controller = null,
                                  $module = null,
                                  array $params = null);
]]></programlisting>

                <para>
                	<code>$accion</code> es siempre necesaria; si ningún controlador es
                	especificado, es asumida una acción en el actual controlador.
                    <code>$module</code> es siempre ignorado a menos que
                    <code>$controller</code> sea especificado. Por último, cualquier
                    <code>$params</code> previsto será adjuntado a la
                    solicitud del objeto. Si no necesita el controlador o el
                    módulo, pero aún tienen que pasar los parámetros, basta con especificar
                    null para esos valores.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerotwo">
        <title>Migrando desde 0.2.0 o antes de 0.6.0</title>

        <para>
        	El mas basico uso de los componentes de MVC no ha cambiado; se puede
        	seguir utilizando a cada uno en la siguiente manera:
        </para>

        <programlisting role="php"><![CDATA[
Zend_Controller_Front::run('/path/to/controllers');
]]></programlisting>

        <programlisting role="php"><![CDATA[
/* -- crear una ruta -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user',
                  'user/:username',
                  array('controller' => 'user', 'action' => 'info')
);

/* -- configurarlo en un controlador -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- configurar el directorio controladores y despahcarlos -- */
$ctrl->setControllerDirectory('/path/to/controllers');
$ctrl->dispatch();
]]></programlisting>

        <para>        		
			Alentamos el uso del objeto Response para agregar contenido y
            cabeceras. Esto permitirá una mayor flexibilidad en el formato de salida intercambiando
            (por instancias, JSON o XML en lugar de XHTML) en sus aplicaciones.
            Por defecto, el envío <code> distpach() </code> enviará la respuesta, enviando ambas
            cabeceras y enviando cuanlquier contenido. También se puede tener el controlador front 
            retorne la respuesta usando <code>returnResponse()</code>,
            y luego enviar la respuesta a través de su propia lógica. Una versión futura
            del controlador front puede hacer valer el uso de la respuesta a través de objetos mediante
            la salida de buffers.
        </para>

        <para>        		
			Hay muchas características adicionales que amplían las existentes API,
            y estas son observadas en la documentación.
        </para>

        <para>
        	Los principales cambios que tendrán que ser conscientes de cuando se encuentre
            la subclase de los diversos componentes. Clave entre estos son:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                	<classname>Zend_Controller_Front::distpach()</classname> por defecto
                    intercepta excepciones en la respuesta del objeto, y no los envia
                    en orden de prevenir un sistema de informacion sensitivo de ser 
                    enviado. Se puede anular esto de varias maneras:                    
                </para>

                <itemizedlist>
                    <listitem>
                        <para>
                            Configurar <code>throwExceptions()</code> en el controlador
                            front:
                        </para>
                        <programlisting role="php"><![CDATA[
$front->throwExceptions(true);
]]></programlisting>
                    </listitem>

                    <listitem>
                        <para>
                            Configurar <code>renderExceptions()</code> en la respuesta del 
                            objeto:
                        </para>
                        <programlisting role="php"><![CDATA[
$response->renderExceptions(true);
$front->setResponse($response);
$front->dispatch();

// o:
$front->returnResponse(true);
$response = $front->dispatch();
$response->renderExceptions(true);
echo $response;
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem><para>
            	<classname>Zend_Controller_Dispatcher_Interface::dispatch()</classname>
                ahora acepta y devuelve un <xref linkend="zend.controller.request" />
                objeto en lugar de un despachador simbólico.
            </para></listitem>

            <listitem><para>            	
				<classname>Zend_Controller_Router_Interface::route()</classname>
                ahora acepta y devuelve un <xref linkend="zend.controller.request" />
                objeto en lugar de un despachador simbólico.                 
            </para></listitem>

            <listitem>
                <para><classname>Zend_Controller_Action</classname> los cambios incluyen:</para>

                <itemizedlist>
                    <listitem><para>
                    	El constructor acepta ahora exactamente tres argumentos,
                        <classname> Zend_Controller_Request_Abstract $request</classname>
                        <classname> Zend_Controller_Response_Abstract $response</classname>
                        y <code> array $ params (opcional) </code>.
                        <classname> Zend_Controller_Action::__construct()</classname> usa
                        los argumentos para para configurar la petición, la respuesta, y propiedades
                        invokeArgs del objeto, y si se sobrecarga el
                        constructor se debe hacer lo mismo. Mejor aún, use
                        el método <code>init()</code> para hacer cualquier configuración
                        a la instancia, ya que este método es llamado como la acción 
                        final del constructor.
                    </para></listitem>

                    <listitem><para>
                    	<code>run()</code>, ya no se define como definitivo, pero es
                        también no utilizado por el controlador front; su único
                        objetivo es para el uso de la clase como un controlador de página. Ello
                        ahora tiene dos argumentos opcionales, uno
                        <classname> Zend_Controller_Request_Abstract $request</classname>
                        y <classname> Zend_Controller_Response_Abstract $response</classname>.
                    </para></listitem>

                    <listitem><para>
                    	<code>indexAction()</code>ya no necesita ser
                         definido, pero se recomienda como acción por defecto. Esto
                         permite utilizar RewriteRouter y la acción controladores para 
                         especificar los diferentes métodos de acción.
                    </para></listitem>

                    <listitem><para>
                        <code>__call()</code> debería ser sobrecargado para manejar las
                        indefinidas acciones automaticamente.
                    </para></listitem>

                    <listitem><para>                    	
						<code>_redirect ()</code> ahora toma un segundo opcional
                        argumento, el código HTTP a retornar con la redirección, y
                        un opcional tercer argumento, <code>$prependBase</code>,
                        que puede indicar que la URL base registrada en la
                        solicitud del objeto debería ser añadido a la URL especificada.
                    </para></listitem>

                    <listitem>
                        <para>                        		
							La propiedad <code>_action</code> ya no está configurada.
                            Esta propiedad fue un <classname> Zend_Controller_Dispatcher_Token </classname>,
                            el cual ya no existe en la actual encarnación.
                            El único propósito de la muestra era proporcionar
                            información sobre la solicitud del controlador, acción,
                            y los parámetros URL. Esta información es ahora
                            disponible en la solicitud del objeto, y puede acceder
                            como sigue:
                        </para>

                        <programlisting role="php"><![CDATA[
// Recuperar las solicitud del nombre del controlador
// El acceso ha sido a través: $this->_action->getControllerName().
// El ejemplo siguiente usa getRequest(), aunque se pueda acceder
// directamente a la $_request property; usar getRequest() es recomendado como
// una clase padre pueda sobrecargar el acceso a la solicitud del objeto.
$controller = $this->getRequest()->getControllerName();

// Recuperar la solicitud del nombre de la accion
// El acceso ha sido a través: $this->_action->getActionName().
$action = $this->getRequest()->getActionName();

// Recuperar la solicitud de los parametros
// Esto no ha cambiado; Los métodos _getParams() y _getParam() simplemente
// proxy a la solictud del objeto.
$params = $this->_getParams();
// solicitud 'foo' parametro, usando 'default' como valor por defecto si no lo encuentra
$foo = $this->_getParam('foo', 'default');
]]></programlisting>
                    </listitem>

                    <listitem>
                        <para>
                        	<code>noRouteAction()</code> ha sido eliminado. La
                            manera adecuada de manejar inexistentes métodos 
                            de acciones se desearia enrutarlos a una 
                            acción por defecto utilizando <code>__call()</code>:
                        </para>

                        <programlisting role="php"><![CDATA[
public function __call($method, $args)
{
    // If an unmatched 'Action' method was requested, pass on to the
    // default action method:
    if ('Action' == substr($method, -6)) {
        return $this->defaultAction();
    }

    throw new Zend_Controller_Exception('Invalid method called');
}
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem><para>
                <classname>Zend_Controller_RewriteRouter::setRewriteBase()</classname> ha
                sido eliminado. Use <classname>Zend_Controller_Front::setBaseUrl()</classname>
                en lugar de (o <classname>Zend_Controller_Request_Http::setBaseUrl()</classname>, si esta usando
                la petición de la clase).
            </para></listitem>

            <listitem><para>            
				<classname>Zend_Controller_Plugin_Interface</classname> se reemplazó 
                por <classname> Zend_Controller_Plugin_Abstract</classname>. Ahora todos los métodos
                aceptan y devuelven un objeto <xref linkend="zend.controller.request" />
                en lugar de un despachador simbólico.
            </para></listitem>
        </itemizedlist>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->