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. Como los segmentos traducidos fueron presentados en la nueva standard route, El caracter @ 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 @ como prefijo. La misma regla se aplica ahora para el caracter : . Los usuarios llamaron nuestra atención el hecho de que Zend_Controller_Action_Helper_ViewRenderer 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: formatModuleName() : 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 Zend_Controller_Action debería usar Los usuarios atrajeron nuestra atención con el hecho de que Zend_Controller_Front y Zend_Controller_Router_Route_Module 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: getDefaultModule() : debe retornar el nombre del módulo por defecto. getDefaultControllerName() : debe retornar el nombre del controlador por defecto. getDefaultAction() : debe retornar el nombre de la acción por defecto. 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" undocumented que ha cambiado. Al escribir las URL s, 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 podría 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. 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'. 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. Si usted nota que estaba dependiendo en esta "caracteristica", usted tiene muchas opciones: 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. Segunda mejor opción: La vista ViewRenderer delega ahora resoluciones de scripts de vistas a Zend_Filter_Inflector ; se puede modificar las normas del inflector para que ya no separe las palabras de una acción con un guión: getInflector(); $inflector->setFilterRule(':action', array( new Zend_Filter_PregReplace( '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i', '' ), 'StringToLower' )); ]]> 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 hacer el nombre de script de vista actual camelCased también. 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. La opción menos deseable: Usted puede forzar al despachador para despachar nombres de acción camelCased con un nuevo controlador bandera, 'useCaseSensitiveActions': setParam('useCaseSensitiveActions', true); ]]> 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. Note, también, el uso de esta bandera aumentará un aviso de que este uso es obsoleto. Los cambios principales introducidos en 1.0.0RC1 son la introducción de y la activación por defecto del plugin ErrorHandler y de acción ayuda ViewRenderer Por favor, lea la documentación de cada uno completamente para ver cómo funcionan y qué efecto pueden tener en sus aplicaciones. El plugin ErrorHandler corre durante postDispatch () 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 noErrorHandler : setParam('noErrorHandler', true); ]]> La acción de ayuda ViewRenderer 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 ViewRenderer intentará generar un scrip de vista basado en el nombre de la acción. Existen varias estrategias que se puede tomar para actualizar su código. En el corto plazo, se puede deshabilitar globalmente ViewRenderer en su controlador frontal bootstrap antes del despache: setParam('noViewRenderer', true); ]]> Sin embargo, esta no es una buena estrategia a largo plazo, eso significa que es probable que usted escriba mas código. Cuando se esta listo para empezar a usar la funcionalidad ViewRenderer , 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: Llamar a $this->render() Llamar a $this->_forward() Llamar a $this->_redirect() Llamar a el Redirector action helper La forma mas fácil de cambiar es deshabilitar auto-rendering para ese método: _helper->viewRenderer->setNoRender(); ]]> 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 preDispatch () o de init() métodos: _helper->viewRenderer->setNoRender() // .. do other things... } ]]> Si se está llamando a render() , y si está usando la Convención Modular de estructura de directorios , usted preferirá cambiar su código a hacer uso del auto envio: Si se esta enviando scripts de vistas multiples en una sóla acción, usted no necesoita cambiar nada. Si se está simplemente llamando render() sin ningún argumento, se puede remover tales líneas. 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 $this->_helper->viewRenderer() . 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 ViewRenderer . Pro favor leer la docuemntación de ViewRenderer para información de esos métodos. 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 ViewRenderer con este objeto. Esto puede ser terminado facilmente en cualquier momento. Antes de despachar una instancia del controlador frontal: Cualquier momento el processo bootstrap: setView($view); ]]> Existen muchas vias para modificar ViewRenderer , 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 ViewRenderer . Le animamos a adaptar el código para utilizar el ErrorHandler y ViewRenderer , ya que son ahora funcionalidad básica. 0.9.3 introduce action helpers . Como parte de este cambio, los siguientes métodos han sido removidos ya que ahora son encapsulados en redirector action helper : setRedirectCode() ; usa Zend_Controller_Action_Helper_Redirector::setCode() . setRedirectPrependBase() ; usa Zend_Controller_Action_Helper_Redirector::setPrependBase() . setRedirectExit() ; usa Zend_Controller_Action_Helper_Redirector::setExit() . Leer la documentación ayudantes de acción para obtener más información sobre cómo recuperar y manipular objetos de ayuda, y la documentación del ayudante redirector para obtener más información sobre la configuración de reorientar las opciones (así como los alternativos métodos para la redirección). Por los cambios previos, el más básico uso de los componentes MVC sigue siendo el mismo: 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: Zend_Controller_Router fue eliminado en favor de reescribir el router. Zend_Controller_RewriteRouter ha sido renombrado a Zend_Controller_Router_Rewrite , y promovido a router estándar enviado con el framework; Zend_Controller_Front lo utilizará por defecto si ningún otro router es sustituido. Una nueva clase ruta para uso con el router reescribir se presentó, Zend_Controller_Router_Route_Module , que abarca la ruta por defecto utilizado por el MVC , y tiene soporte para el controlador de módulos . Zend_Controller_Router_StaticRoute was renamed to Zend_Controller_Router_Route_Static . Zend_Controller_Dispatcher was renamed Zend_Controller_Dispatcher_Standard . Los argumentos de Zend_Controller_Action::_forward() han cambiado. la firma es ahora: $accion es siempre necesaria; si ningún controlador es especificado, es asumida una acción en el actual controlador. $module es siempre ignorado a menos que $controller sea especificado. Por último, cualquier $params 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. El mas basico uso de los componentes de MVC no ha cambiado; se puede seguir utilizando a cada uno en la siguiente manera: 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(); ]]> 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 distpach() enviará la respuesta, enviando ambas cabeceras y enviando cuanlquier contenido. También se puede tener el controlador front retorne la respuesta usando returnResponse() , 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. Hay muchas características adicionales que amplían las existentes API, y estas son observadas en la documentación. Los principales cambios que tendrán que ser conscientes de cuando se encuentre la subclase de los diversos componentes. Clave entre estos son: Zend_Controller_Front::distpach() 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: Configurar throwExceptions() en el controlador front: throwExceptions(true); ]]> Configurar renderExceptions() en la respuesta del objeto: renderExceptions(true); $front->setResponse($response); $front->dispatch(); // o: $front->returnResponse(true); $response = $front->dispatch(); $response->renderExceptions(true); echo $response; ]]> Zend_Controller_Dispatcher_Interface::dispatch() ahora acepta y devuelve un objeto en lugar de un despachador simbólico. Zend_Controller_Router_Interface::route() ahora acepta y devuelve un objeto en lugar de un despachador simbólico. Zend_Controller_Action los cambios incluyen: El constructor acepta ahora exactamente tres argumentos, Zend_Controller_Request_Abstract $request Zend_Controller_Response_Abstract $response y array $ params (opcional) . Zend_Controller_Action::__construct() 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 init() para hacer cualquier configuración a la instancia, ya que este método es llamado como la acción final del constructor. run() , 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 Zend_Controller_Request_Abstract $request y Zend_Controller_Response_Abstract $response . indexAction() 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. __call() debería ser sobrecargado para manejar las indefinidas acciones automaticamente. _redirect () ahora toma un segundo opcional argumento, el código HTTP a retornar con la redirección, y un opcional tercer argumento, $prependBase , que puede indicar que la URL base registrada en la solicitud del objeto debería ser añadido a la URL especificada. La propiedad _action ya no está configurada. Esta propiedad fue un Zend_Controller_Dispatcher_Token , 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: _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'); ]]> noRouteAction() ha sido eliminado. La manera adecuada de manejar inexistentes métodos de acciones se desearia enrutarlos a una acción por defecto utilizando __call() : defaultAction(); } throw new Zend_Controller_Exception('Invalid method called'); } ]]> Zend_Controller_RewriteRouter::setRewriteBase() ha sido eliminado. Use Zend_Controller_Front::setBaseUrl() en lugar de (o Zend_Controller_Request_Http::setBaseUrl() , si esta usando la petición de la clase). Zend_Controller_Plugin_Interface se reemplazó por Zend_Controller_Plugin_Abstract . Ahora todos los métodos aceptan y devuelven un objeto en lugar de un despachador simbólico.