Previous Next

Action Helpers


Action Helpers allow developers to inject runtime and/or on-demand functionality into any Action Controllers that extend Zend_Controller_Action. Action Helpers aim to minimize the necessity to extend the abstract Action Controller in order to inject common Action Controller functionality.

There are a number of ways to use Action Helpers. Action Helpers employ the use of a brokerage system, similar to the types of brokerage you see in Zend_View_Helper, and that of Zend_Controller_Plugin. Action Helpers (like Zend_View_Helper) may be loaded and called on demand, or they may be instantiated at request time (bootstrap) or action controller creation time ( init()). To understand this more fully, please see the usage section below.

Helper Initialization

A helper can be initialized in several different ways, based on your needs as well as the functionality of that helper.

The helper broker is stored as the $_helper member of Zend_Controller_Action; use the broker to retrieve or call on helpers. Some methods for doing so include:

  • Explicitly using getHelper(). Simply pass it a name, and a helper object is returned:

    $flashMessenger = $this->_helper->getHelper('FlashMessenger');
    $flashMessenger->addMessage('We did something in the last request');
  • Use the helper broker's __get() functionality and retrieve the helper as if it were a member property of the broker:

    $flashMessenger = $this->_helper->FlashMessenger;
    $flashMessenger->addMessage('We did something in the last request');
  • Finally, most action helpers implement the method direct() which will call a specific, default method in the helper. In the example of the FlashMessenger, it calls addMessage():

    $this->_helper->FlashMessenger('We did something in the last request');


All of the above examples are functionally equivalent.

You may also instantiate helpers explicitly. You may wish to do this if using the helper outside of an action controller, or if you wish to pass a helper to the helper broker for use by any action. Instantiation is as per any other PHP class.

The Helper Broker

Zend_Controller_Action_HelperBroker handles the details of registering helper objects and helper paths, as well as retrieving helpers on-demand.

To register a helper with the broker, use addHelper():


Of course, instantiating and passing helpers to the broker is a bit time and resource intensive, so two methods exists to automate things slightly: addPrefix() and addPath().

  • addPrefix() takes a class prefix and uses it to determine a path where helper classes have been defined. It assumes the prefix follows Zend Framework class naming conventions.

    // Add helpers prefixed with My_Action_Helpers in My/Action/Helpers/
  • addPath() takes a directory as its first argument and a class prefix as the second argument (defaulting to 'Zend_Controller_Action_Helper'). This allows you to map your own class prefixes to specific directories.

    // Add helpers prefixed with Helper in Plugins/Helpers/

Since these methods are static, they may be called at any point in the controller chain in order to dynamically add helpers as needed.

Internally, the helper broker uses a PluginLoader instance to maintain paths. You can retrieve the PluginLoader using the static method getPluginLoader(), or, alternately, inject a custom PluginLoader instance using setPluginLoader().

To determine if a helper exists in the helper broker, use hasHelper($name), where $name is the short name of the helper (minus the prefix):

// Check if 'redirector' helper is registered with the broker:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
    echo 'Redirector helper registered';

There are also two static methods for retrieving helpers from the helper broker: getExistingHelper() and getStaticHelper(). getExistingHelper() will retrieve a helper only if it has previously been invoked by or explicitly registered with the helper broker; it will throw an exception if not. getStaticHelper() does the same as getExistingHelper(), but will attempt to instantiate the helper if has not yet been registered with the helper stack. getStaticHelper() is a good choice for retrieving helpers which you wish to configure.

Both methods take a single argument, $name, which is the short name of the helper (minus the prefix).

// Check if 'redirector' helper is registered with the broker, and fetch:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
    $redirector =

// Or, simply retrieve it, not worrying about whether or not it was
// previously registered:
$redirector =

Finally, to delete a registered helper from the broker, use removeHelper($name), where $name is the short name of the helper (minus the prefix):

// Conditionally remove the 'redirector' helper from the broker:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {

Built-in Action Helpers

Zend Framework includes several action helpers by default: AutoComplete for automating responses for AJAX autocompletion; ContextSwitch and AjaxContext for serving alternate response formats for your actions; a FlashMessenger for handling session flash messages; Json for encoding and sending JSON responses; a Redirector, to provide different implementations for redirecting to internal and external pages from your application; and a ViewRenderer to automate the process of setting up the view object in your controllers and rendering views.


El helper ActionStack le permite empujar requerimientos al ActionStack plugin del front controller, el cual le ayuda efectivamente a crear una cola de acciones a ejecutar durante la solicitud. El helper le permite añadir actions ya sea mediante la especificación de los objetos o una nueva solicitud action - controller - module.

Nota: Invocando al Ayudante ActionStack Inicializa el Plugin de ActionStack

Invocando al helper ActionStack implicitamente registra el plugin de ActionStack -- lo que significa que no necesita registrar explícitamente el plugin de ActionStack para utilizar esta funcionalidad.

Ejemplo #1 Agregando una Tarea Usando Nombres de Acción, Controllador y Módulo

A menudo, es más sencillo simplemente especificar la acción, el controlador y el módulo (y parámetros opcionales de requerimientos), tal como cuando llama a Zend_Controller_Action::_forward() :

class FooController extends Zend_Controller_Action
    public function barAction()
        // Agregar dos acciones a la pila (stack)
        // Y llamar a  /foo/baz/bar/baz
        // (FooController::bazAction() con el requrimiento var bar == baz)
                                    array('bar' => 'baz'));

        // Agregar la llamada a /bar/bat
        // (BarController::batAction())
        $this->_helper->actionStack('bat', 'bar');

Ejemplo #2 Agregando una Tarea al Objeto Solicitud (Request)

A veces la naturaleza OOP de un objeto solicitud tiene más sentido; puede pasar también tal objeto al ayudante ActionStack .

class FooController extends Zend_Controller_Action
    public function barAction()
        // Agregar dos acciones al stack
        // Agregar la llamada a /foo/baz/bar/baz
        // (FooController::bazAction() with request var bar == baz)
        $request = clone $this->getRequest();
        // No establezca controlador o módulo; use los valores actuales
                ->setParams(array('bar' => 'baz'));

        // Agregar la llamada a /bar/bat
        // (BarController::batAction())
        $request = clone $this->getRequest();
        // no establezca módulo; use el valor actual


Muchas bibliotecas de Javascript con AJAX ofrecen funcionalidad para proporcionar autocompletado según la cual un selectlist de resultados potencialmente concordantes se visualiza a medida que el usuario tipea. El ayudante AutoComplete pretende simplificar el retorno de respuestas aceptables a esos métodos.

Dado que no todas la bibliotecas JS implementan el autocompletado de la misma manera, el ayudante AutoComplete ofrece algunas funcionalidades abstractas de base necesarias para muchas bibliotecas, e implementaciones concretas para distintas bibliotecas. Los tipos de datos de retorno son generalmente o bien arrays de strings JSON , array de arrays JSON (donde cada miembro del array está en un array asociativo de metadatos utilizado para crear la selectlist), o HTML .

El uso básico para cada aplicación es el mismo:

class FooController extends Zend_Controller_Action
    public function barAction()
        // Ejecutar alguna lógica...

        // Codificar y enviar la respuesta;

        // O explicitamente:
        $response = $this->_helper->autoCompleteDojo

        // O prepare simplemente la respuesta de autocompletado:
        $response = $this->_helper->autoCompleteDojo

Por defecto, el autocompletado hace lo siguiente:

  • Desactiva esquemas y a ViewRenderer.

  • Establece las cabeceras apropiadas para la respuesta.

  • Establece el cuerpo de la respuesta con datos codificados o formateados para autocompletar.

  • Envía la respuesta.

Los métodos disponibles para el ayudante incluyen:

  • disableLayouts() puede ser utilizada para desactivar esquemas y a ViewRenderer. Típicamente, esto se llama dentro de prepareAutoCompletion() .

  • encodeJson($data, $keepLayouts = false) codificará datos a JSON , y opcionalmente habilitando o deshabilitando esquemas. Típicamente, esto se llama dentro de prepareAutoCompletion() .

  • prepareAutoCompletion($data, $keepLayouts = false) se utiliza para preparar datos en el formato necesario de la respuesta para la aplicación concreta, opcionalmente los esquemas pueden habilitarse o deshabilitarse. El valor de retorno variará dependiendo de la implementación.

  • sendAutoCompletion($data, $keepLayouts = false) se utiliza para preparar datos en el formato necesario de la respuesta para la aplicación concreta. Esta llama a prepareAutoCompletion() , y entonces envía la respuesta.

  • direct($data, $sendNow = true, $keepLayouts = false) se utiliza cuando se llama al ayudante como un método del ayudante intermediario. El flag $sendNow se utiliza para determinar si se debe llamar a sendAutoCompletion() o a prepareAutoCompletion() , respectivamente.

Actualmente, AutoComplete soporta las bibliotecas AJAX de Dojo y Scriptaculous.

AutoCompletado con Dojo

Dojo no tiene un widget de autocompletado per se, pero tiene dos widgets que pueden ejecutar AutoCompletado: ComboBox y FilteringSelect. En ambos casos, necesitan de un almacén de datos que implemente QueryReadStore; para obtener más información sobre estos temas, ver la documentación en »

En Zend Framework, puede pasar un simple array indexado al ayudante AutoCompleteDojo, y este regresará una adecuada respuesta JSON para su uso como almacenamiento:

// dentro del controlador de acción:

Ejemplo #3 AutoCompletion con Dojo Usando Zend MVC

AutoCompletion con Dojo via Zend MVC requiere varias cosas: generar un objeto form para el ComboBox en el que usted quiere AutoCompletado, un controlador de acción para prestar servicio a los resultados de AutoCompletion, creando un QueryReadStore personalizado para conectar a la acción AutoCompletion, y la generación del Javascript a utilizar en la inicializción de AutoCompletion del lado del servidor.

En primer lugar, veamos el Javascript necesario. Dojo ofrece un marco completo para crear Javascript OOP , tal como lo hace Zend Framework para PHP . Parte de eso es la capacidad de crear pseudo-namespaces utilizando la jerarquía de directorios. Crearemos un directorio 'custom' en el mismo nivel en el cual el directorio de Dojo forma parte de la distribución Dojo. Dentro del directorio, crearemos un archivo Javascript, TestNameReadStore.js , con el siguiente contenido:

dojo.declare("custom.TestNameReadStore",, {
    fetch:function (request) {
        request.serverQuery = { };
        return this.inherited("fetch", arguments);

Esta clase es simplemente una extensión del propio QueryReadStore de Dojo, que es de por sí misma una clase abstracta. Simplemente definimos un método por el cual realizamos la solicitud, y se le asigna al elemento 'test'.

A continuación, vamos a crear el elemento form para el que queremos AutoCompletion:

class TestController extends Zend_Controller_Action
    protected $_form;

    public function getForm()
        if (null === $this->_form) {
            $this->_form = new Zend_Form();
                    $this->getRequest()->getBaseUrl() . '/test/process'
                    'test' => array('type' => 'text', 'options' => array(
                        'filters'        => array('StringTrim'),
                        'dojoType'       => array('dijit.form.ComboBox'),
                        'store'          => 'testStore',
                        'autoComplete'   => 'false',
                        'hasDownArrow'   => 'true',
                        'label' => 'Your input:',
                    'go' => array('type' => 'submit',
                                  'options' => array('label' => 'Go!'))
        return $this->_form;

Aquí, estamos simplemente creando un formulario con los métodos 'test' y 'go'. El método 'test' agrega varios atributos especiales específicos de Dojo: dojoType, store, AutoComplete y hasDownArrow. El dojoType es utilizado para indicar que estamos creando un ComboBox, y que vamos a vincularlo a un almacén de datos (clave 'store') de 'testStore' -- veremos más de esto más adelante. Especificando ' AutoComplete ' como FALSE se le dice a Dojo que no seleccione automáticamente el primer acierto, sino mostrar una lista de aciertos. Por último, 'hasDownArrow' crea una flecha abajo similar a un select box para que podamos mostrar y ocultar los aciertos o concordancias.

Vamos a añadir un método para mostrar la forma, así como un punto final para el procesamiento de AutoCompletion:

class TestController extends Zend_Controller_Action
    // ...

     * Página final
    public function indexAction()
        $this->view->form = $this->getForm();

    public function autocompleteAction()
        if ('ajax' != $this->_getParam('format', false)) {
            return $this->_helper->redirector('index');
        if ($this->getRequest()->isPost()) {
            return $this->_helper->redirector('index');

        $match = trim($this->getRequest()->getQuery('test', ''));

        $matches = array();
        foreach ($this->getData() as $datum) {
            if (0 === strpos($datum, $match)) {
                $matches[] = $datum;

En nuestro autocompleteAction() hacemos una serie de cosas. En primer lugar, esperamos a asegurarnos de que tengamos una petición post, y que existe un parámetro 'form' establecido al valor 'ajax'; esto es simplemente para ayudar a reducir preguntas espúreas a la acción. A continuación, vamos a comprobar el parámetro 'test', y compararlo contra nuestros datos. (Yo deliberadamente dejé de lado la implementación de getData() aquí -- podría ser cualquier tipo de fuente de datos). Por último, enviamos nuestros aciertos a nuestro ayudante AutoCompletion.

Ahora que tenemos todas las piezas en el backend, veamos lo que necesitamos para entregar en nuestro script de vista para la página final. En primer lugar, necesitamos configurar nuestro data store, luego hacer nuestro formulario, y finalmente garantizar que las biblotecas Dojo apropiadas -- incluyendo que nuestro data store personalizado -- estén cargadas. Veamos el script de vista, el cual comenta los pasos:

form ?> headStyle()->captureStart() ?> @import "baseUrl() ?>/javascript/dijit/themes/tundra/tundra.css"; @import "baseUrl() ?>/javascript/dojo/resources/dojo.css"; headStyle()->captureEnd() ?> headScript() ->setAllowArbitraryAttributes(true) ->appendFile($this->baseUrl() . '/javascript/dojo/dojo.js', 'text/javascript', array('djConfig' => 'parseOnLoad: true')) ->captureStart() ?> djConfig.usePlainJson=true; dojo.registerModulePath("custom","../custom"); dojo.require("dojo.parser"); dojo.require(""); dojo.require("dijit.form.ComboBox"); dojo.require("custom.TestNameReadStore"); headScript()->captureEnd()

Note que las llamadas a los ayudantes de vista como headStyle y headScript; son ubicadores, que podemos suministrar a la sección 'head' del HTML de nuestro script de vista.

Ahora tenemos todas las piezas para que el AutoCompletion de Dojo pueda trabajar.

AutoCompletion con Scriptaculous

» Scriptaculous espera una respuesta HTML en un formato específico.

El ayudante para utilizar con esta biblioteca es 'AutoCompleteScriptaculous'. Simplemente proporcionarle un array de datos, y el ayudante creará una respuesta HTML compatible con Ajax.Autocompleter.

ContextSwitch con AjaxContext

El ayudante de acción ContextSwitch está destinado a facilitar el regreso de respuestas de diferentes formatos de solicitud. El helper AjaxContext es una versión especializada de ContextSwitch que facilita el regreso de respuestas a XmlHttpRequests.

Para habilitar alguno, usted debe proporcionar indicios en su controlador de qué acciones pueden responder a que contextos. Si una solicitud entrante indica un contexto válido para la acción determinada, entonces el ayudante:

  • Deshabilita los esquemas, si están habilitados.

  • Establecer un sufijo de vista alternativo, requiriendo de manera efectiva un script de vista separado para el contexto.

  • Envía las cabeceras de respuesta apropiadas para el contexto deseado.

  • Opcionalmente, llama a llamadas de retorno especifícas para configurar el contexto y/o realizar post-procesamiento.

Como ejemplo, tomemos el siguiente controlador:

class NewsController extends Zend_Controller_Action
     * Página final; enviar a listAction()
    public function indexAction()

     * Lista nuevos items
    public function listAction()

     * Vista del nuevo item
    public function viewAction()

Digamos que queremos que listAction() también esté disponible en un formato XML . En lugar de crear una acción diferente, podemos indicarle que puede devolver una respuesta XML :

class NewsController extends Zend_Controller_Action
    public function init()
        $contextSwitch = $this->_helper->getHelper('contextSwitch');
        $contextSwitch->addActionContext('list', 'xml')

    // ...

Esto es lo que hará:

  • Establecer la cabecera de respuesta 'Content-Type' a ' text/xml '.

  • Cambiar el sufijo de vista de ' xml.phtml ' (o, si usa un sufifo de vista alternativo, 'xml.[su sufijo]').

Ahora, necesitará crear un nuevo script de vista, news/list.xml.phtml ', que creará y mostrará a XML .

Para determinar si una solicitud debe iniciar un cambio de contexto, el ayudante comprueba si hay un token en el objeto solicitud. Por defecto, busca el parámetro 'format', aunque esto puede ser configurado. Esto significa que, en muchos casos, para provocar un cambio de contexto, puede agregar un parámetro 'format' a su solicitud:

  • Via parámetro URL : /news/list/format/xml (recordar que el valor por defecto del esquema de ruteo permite pares arbitrarios de clave/valor tras la acción).

  • Via parámetro GET : /news/list?format=xml

ContextSwitch le permite especificar contextos arbitrarios, incluso qué sufijo cambiará (si hay alguno), cualquier cabecera de respuesta que deba ser enviada, y callbacks arbitrarios para la inicialización y posterior procesamiento.

Contextos Disponibles por Defecto

Por defecto, dos contextos están a disposición del ayudante ContextSwitch : JSON y XML .

  • JSON . El contexto JSON establece la cabecera de respuesta 'Content-Type' a ' application/json ', y el sufijo del script de vista a ' json.phtml '.

    Sin embargo, por defecto, no es necesario un script de vista. Simplemente serializará todas las variables de la vista, y emitirá la respuesta JSON inmediatamente.

    Este comportamiento puede ser desactivado apagando la serialización automática de JSON :

  • XML . El contexto XML establece la cabecera de respuesta 'Content-Type' a ' text/xml ', y el sufijo del script de vista a ' xml.phtml '. Necesitará crear un script de vista nuevo para el contexto.

Creando Contextos Personalizados

A veces, los contextos por defecto no son suficientes. Por ejemplo, puede que desee devolver YAML , o PHP serializado, un RSS o ATOM feed, etc. ContextSwitch le permite hacerlo.

La forma más fácil para añadir un nuevo contexto es a través del método addContext() . Este método tiene dos argumentos, el nombre del contexto, y un array de especificación. La especificación debería incluir uno o más de los siguientes:

  • suffix : el sufijo a anteponer al sufijo de la vista por defecto tal como está registrado en ViewRenderer.

  • headers : un array de pares cabecera/valor que desea enviar como parte de la respuesta.

  • callbacks : un array que contiene una o más de las claves 'init' o 'post', apuntando a callbacks PHP válidos que pueden utilizarse para inicializar el contexto y posterior procesamiento.

    La inicialización de callbacks ocurre cuando el contexto es detectado por ContextSwitch . Usted puede usarlo para ejecutar una lógica arbitraria. Por ejemplo, el contexto JSON utiliza un callback para desactivar a ViewRenderer cuando está activada la serialización auto-JSON.

    El post procesamiento ocurre durante la rutina de la acción postDispatch() , y puede ser utilizada para ejecutar una lógica arbitraria. Como ejemplo, el contexto JSON utiliza un callback para determinar si la serialización auto-JSON está activada; si así fuera, serializa las variables de la vista a JSON y envía la respuesta, pero si no, re-habilita a ViewRenderer.

Hay una variedad de métodos para interactuar con contextos:

  • addContext($context, array $spec) : agrega un nuevo contexto. Lanza una excepción si el contexto ya existe.

  • setContext($context, array $spec) : añade un nuevo contexto o sobrescribirá un contexto existente. Usa la misma especificación que addContext() .

  • addContexts(array $contexts) : añade muchos contextos de una vez. El array $contexts debería ser un array de pares contexto/especificación. Si alguno de los contextos ya existe, arrojará una excepción.

  • setContexts(array $contexts) : añade nuevos contextos y sobreescribe los existentes. Usa la misma especificación que addContexts() .

  • hasContext($context) : devuelve TRUE si el contexto existe, FALSE de lo contrario.

  • getContext($context) : recupera un único contexto por su nombre. Devuelve un array siguiendo la especificación usada en addContext() .

  • getContexts() : recupera todos los contextos. Devuelve un array de pares contexto/especificación.

  • removeContext($context) : elimina un único contexto por su nombre. Devuelve TRUE si tiene éxito, FALSE si el contexto no fue encontrado.

  • clearContexts() : elimina todos los contextos.

Estableciendo los Contextos por Acción

Hay dos mecanismos para establecer contextos disponibles. Puede crear manualmente los arrays en su controlador, o utilizar varios métodos en ContextSwitch para ensamblarlos.

El método principal para añadir relaciones acción/contexto es addActionContext() . Se esperan dos argumentos, la acción a la que el contexto se añade, y el nombre de un contexto o un array de contextos. Como ejemplo, considere la siguiente clase controlador:

class FooController extends Zend_Controller_Action
    public function listAction()

    public function viewAction()

    public function commentsAction()

    public function updateAction()

Supongamos que queremos añadir un contexto XML a la acción 'list', y contextos XML y JSON a la acción 'comments'. Podríamos hacerlo en el método init() :

class FooController extends Zend_Controller_Action
    public function init()
             ->addActionContext('list', 'xml')
             ->addActionContext('comments', array('xml', 'json'))

Alternativamente, puede simplemente definir la propiedad del array $context :

class FooController extends Zend_Controller_Action
    public $contexts = array(
        'list'     => array('xml'),
        'comments' => array('xml', 'json')

    public function init()

El anterior es el menos sobrecargado, pero también está expuesto a posibles errores.

Los siguientes métodos pueden ser utilizados para construir los mapeos del contexto:

  • addActionContext($action, $context) : marca uno o más contextos como disponibles para una acción. Si ya existen los mapeos, simplemente se añade a esos mapeos. $context puede ser un único contexto, o un array de contextos.

    Un valor de TRUE para el contexto marcará todos los contextos como disponibles para la acción.

    Un valor vacío de $contexto desactivará todos los contextos para la acción determinada.

  • setActionContext($action, $context) : marca uno o más contextos como disponibles para una acción. Si el mapeo ya existe, se reemplaza con los especificados. $context puede ser un único contexto, o un array de contextos.

  • addActionContexts(array $contexts) : agrega varios pares acción/contexto de una vez. $contexts debe ser un array asociativo de pares acción/contexto. Le pasa la petición a addActionContext() , lo que significa que si los emparejamientos ya existen, se añade a ellos.

  • setActionContexts(array $contexts) : actúa como addActionContexts() , pero sobreescribe pares de acción/contexto existentes.

  • hasActionContext($action, $context) : determina si una acción particular tiene un contexto determinado.

  • getActionContexts($action = null) : devuelve o todos los contextos para una acción determinada, o todos los pares de acción/contexto.

  • removeActionContext($action, $context) : elimina uno o más contextos de una acción determinada. $context puede ser un único contexto o un array de contextos.

  • clearActionContexts($action = null) : elimina todos los contextos de una acción determinada, o de todas las acciones con contextos.

Inicializando Conmutación de Contextos (Context Switching)

Para inicializar la conmutación de contexto, necesita llamar a initContext() en su controlador de acción:

class NewsController extends Zend_Controller_Action
    public function init()

En algunos casos, puede querer forzar el contexto utilizado; por ejemplo, puede que sólo quiera permitir el contexto XML si la conmutación de contexto está activada. Puede hacerlo pasando el contexto a initContext() :


Funcionalidad Adicional

Se pueden utilizar una variedad de métodos para alterar el comportamiento del ayudante ContextSwitch . Estos incluyen:

  • setAutoJsonSerialization($flag) : Por defecto, los contextos JSON serializarán cualquier variable de vista a notación JSON y lo devolverán como una respuesta. Si usted desea crear su propia respuesta, debe deshabilitar esta opción; esto debe hacerse antes de llamar a initContext() .


    Puede recuperar el valor del flag con getAutoJsonSerialization() .

  • setSuffix($context, $suffix, $prependViewRendererSuffix) : Con este método, puede especificar un sufijo diferente para utilizarlo en un contexto determinado. El tercer argumento es utilizado para indicar si anteponer o no el actual sufijo de ViewRenderer con el nuevo sufijo; este flag está activado por defecto.

    Pasando un valor vacío para el sufijo hará que sólo el sufijo ViewRenderer será utilizado.

  • addHeader($context, $header, $content) : Añadir una cabecera de respuesta para un determinado contexto. $header es el nombre de la cabecera, y $content es el valor a pasar por esa cabecera.

    Cada contexto pueden tener múltiples cabeceras; addHeader() agrega cabeceras adicionales al stack de cabecera del contexto.

    Si el $header especificado ya existe para el contexto, arrojará una excepción.

  • setHeader($context, $header, $content) : setHeader() actúa igual que addHeader() , excepto que le permite sobreescribir cabeceras del contexto actual.

  • addHeaders($context, array $headers) : Añade varias cabeceras de una vez a un determinado contexto. Delega a addHeader() , así que si la cabecera ya existe, arrojará una excepción. $headers es un array de pares cabecera/contexto.

  • setHeaders($context, array $headers.) : como addHeaders() , excepto que lo delegua a setHeader() , permitiéndole sobreescribir las cabeceras existentes.

  • getHeader($context, $header) : recuperar el valor de una cabecera para un determinado contexto. Retorna null si no existe.

  • removeHeader($context, $header) : eliminar una única cabecera para un determinado contexto.

  • clearHeaders($context, $header) : eliminar todas las cabeceras para un determinado contexto.

  • setCallback($context, $trigger, $callback) : establecer un callback en un determinado disparador para poner en marcha un determinado contexto. Los disparadores pueden ser 'init' o 'post' (indicando que se llamará a un callback para cada contexto de inicialización o postDispatch). $callback debe ser un callback válido de PHP .

  • setCallbacks($context, array $callbacks) : establece varios callbacks para un determinado contexto. $callbacks deben ser pares de diparadores/callbacks. En realidad, la mayor cantidad de callbacks que pueden ser registrados son dos, uno para la inicialización y otro para el procesamiento posterior.

  • getCallback($context, $trigger) : recuperar un callback para un determinado disparador en un contexto dado.

  • getCallbacks($context) : recupera todos los callbacks para un determinado contexto. Devuelve un array de pares disparor/callback.

  • removeCallback($context, $trigger) : elimina un callback para un determinado disparador y contexto.

  • clearCallbacks($context) : elimina todos los callbacks para un determinado contexto.

  • setContextParam($name) : establece el parámetro de petición para comprobar si un conmutador de contexto ha sido solicitado. El valor por defecto es 'format', pero este accededor puede ser utilizado para establecer un valor alternativo.

    getContextParam() puede ser utilizado para recuperar el valor actual.

  • setAutoDisableLayout($flag) : Por defecto, los esquemas están deshabilitados cuando sucede una conmutación de contexto; esto es porque normalmente los esquemas sólo serán utilizados para devolver respuestas normales, y no tienen sentido en otros contextos. Sin embargo, si desea usar esquemas (tal vez puede tener un diseño para el nuevo contexto), puede cambiar este comportamiento pasando un valor falso a setAutoDisableLayout() . Usted debería hacer esto antes de llamar a initContext() .

    Para conseguir el valor de este flag, utilice el accededor getAutoDisableLayout() .

  • getCurrentContext() Puede ser utilizado para determinar qué contexto fue detectado, si hay alguno. Este retorna null si no hubo conmutación de contexto, o si initContext() fue llamado antes de ser invocado.

Funcionalidad de AjaxContext

El ayudante AjaxContext extiende ContextSwitch , así que toda de la funcionalidad listada para ContextSwitch está disponible. Hay algunas diferencias fundamentales, sin embargo.

En primer lugar, el controlador de acción utiliza una propiedad diferente para determinar contextos, $ajaxable . Esto es, que puede tener diferentes contextos utilizados para AJAX versus peticiones normales HTTP . Los diversos métodos *ActionContext*() de AjaxContext le escribirán a esta propiedad.

En segundo lugar, sólo se disparará si se produjo un XmlHttpRequest, según lo determinado por la solicitud del método del objeto isXmlHttpRequest() . Así, si se pasa el parámetro de contexto ('format') en la solicitud, pero la solicitud no fue hecha como un XmlHttpRequest, no se disparará ninguna conmutación de contexto.

En tercer lugar, AjaxContext agrega un contexto adicional, HTML . En este contexto, se establece el sufijo a ' ajax.phtml ' para diferenciar el contexto de una solicitud normal. No se devuelven cabeceras adicionales.

Ejemplo #4 Permitiendo a las Acciones Responder a Requerimientos Ajax

En el siguiente ejemplo, estamos permitiendo requerimientos a las acciones 'view', 'form', y 'process' para responder a peticiones AJAX . En los dos primeros casos, 'view' y 'form', devolveremos fragmentos (snippets) de HTML con los cuales actualizaremos la página; y en el último, devolveremos JSON .

class CommentController extends Zend_Controller_Action
    public function init()
        $ajaxContext = $this->_helper->getHelper('AjaxContext');
        $ajaxContext->addActionContext('view', 'html')
                    ->addActionContext('form', 'html')
                    ->addActionContext('process', 'json')

    public function viewAction()
        // Tirar para ver un único comentario.
        // Cuando se detecta AjaxContext, utiliza el script de vista
        // comment/view.ajax.phtml.

    public function formAction()
        // Mostrar el form "add new comment".
        // Cuando se detecta AjaxContext, utiliza el script de vista
        // comment/form.ajax.phtml.

    public function processAction()
        // Procesar un nuevo comentario
        // Devolver los resultados como JSON; simplemente asignar los
        // resultados como variables de la vista, y se devolverán como JSON.


En el lado del cliente, su biblioteca AJAX simplemente pedirá los parámetros finales ' /comment/view ', ' /comment/form ', y ' /comment/process ', y pasar el parámetro 'format': ' /comment/view/format/html ', ' /comment/form/format/html ', ' /comment/process/format/json '. (O puede pasar el parámetro via string de consulta: ejemplo "?format=json").

Asumiendo que su biblioteca pasa la cabecera 'X-Requested-With:XmlHttpRequest' entonces estas acciones devolverán la respuesta en el formato apropiado.



El ayudante FlashMessenger le permite pasar mensajes que el usuario puede querer ver en la próxima solicitud. Para lograrlo, FlashMessenger usa Zend_Session_Namespace para almacenar los mensajes para las futuras o próxima solicitud de recuperación. Es una buena idea si planea utilizar Zend_Session o Zend_Session_Namespace , que inicializa con Zend_Session::start() en su archivo bootstrap. (Para más detalles de su uso vea la documentación en Zend_Session ).

Ejemplo Básico de Uso

El ejemplo de uso de abajo muestra el uso del flash messenger en su forma más elemental. Cuando se llama la acción /some/my , añade el mensaje de flash "Record Saved!". Una solicitud posterior a la acción /some/my-next-request lo recuperará (y entonces también lo suprimirá).

class SomeController extends Zend_Controller_Action
     * FlashMessenger
     * @var Zend_Controller_Action_Helper_FlashMessenger
    protected $_flashMessenger = null;

    public function init()
        $this->_flashMessenger =

    public function myAction()
         * Método por defecto para obtener un instancia por demanda de
         * Zend_Controller_Action_Helper_FlashMessenger
        $this->_flashMessenger->addMessage('Record Saved!');

    public function myNextRequestAction()
        $this->view->messages = $this->_flashMessenger->getMessages();


Las respuestas JSON se están convirtiendo en la respuesta de elección cuando se trata de requerimientos AJAX que esperan recibir respuestas datasets; en el lado del cliente, JSON puede ser inmediatamente parseado y ejecutado rápidamente.

El ayudante de acción de JSON hace varias cosas:

  • Deshabilita los layouts si estuvieran habilitados.

  • Opcionalmente, un array de opciones que pasar como segundo argumento a Zend_Json::encode() . Este array de opciones permite habilitar layouts y codificación utilizando Zend_Json_Expr .

    $this->_helper->json($data, array('enableJsonExprFinder' => true));
  • Desactiva la ViewRenderer si está actualmente habilitada.

  • Establece la cabecera de respuesta 'Content-Type' a ' application/json '.

  • Por defecto, devuelve inmediatamente la respuesta, sin esperar a la acción para finalizar la ejecución.

El uso es simple: o bien llamarlo como un método del ayudante, o llamar a uno de los métodos encodeJson() o sendJson() :

class FooController extends Zend_Controller_Action
    public function barAction()
        // hacer algún procesamiento...
        // Enviar la respuesta JSON:

        // o...

        // o recuperar json:
        $json = $this->_helper->json->encodeJson($data);

Nota: Conservando los Esquemas(Layouts)

Si se tiene un esquema separado para respuestas de JSON -- quizás para envolver la respuesta de JSON en algún tipo de contexto -- cada método en el ayudante JSON acepta un segundo argumento opcional: un flag para activar o desactivar layouts. Pasando un valor booleano TRUE conservará los layouts habilitados:

$this->_helper->json($data, true);

Opcionalmente, puede pasar un array como el segundo parámetro. Este array puede contener una variedad de opciones, incluida la opción keepLayouts :

$this->_helper->json($data, array('keepLayouts' => true);

Nota: Habilitando la Codificación usando Zend_Json_Expr

Zend_Json::encode() permite la codificación de expresiones nativas de JSON utilizando objetos Zend_Json_Expr . Esta opción está desactivada por defecto. Para activar esta opción, pase un valor booleano TRUE a la opción enableJsonExprFinder :

$this->_helper->json($data, array('enableJsonExprFinder' => true);

Si desea hacer esto, debe pasar un array como segundo argumento. Esto también le permite combinar otras opciones, como la opción keepLayouts . Todas esas opciones se pasan luego a Zend_Json::encode() .

$this->_helper->json($data, array(
    'enableJsonExprFinder' => true,
    'keepLayouts'          => true,



El ayudante Redirector le permite utilizar un objeto de redireccionamiento para cumplir con necesidades de su aplicación para redireccionar a una nueva URL . Ofrece numerosas ventajas sobre el método _redirect() , tales como poder preconfigurar un comportamiento para todo el sitio en el objeto redirector o usando el construido en gotoSimple($action, $controller, $module, $params) , interfaz similar a la de Zend_Controller_Action::_forward() .

El Redirector tiene un número de métodos que pueden utilizarse para afectar el comportamiento al redireccionar:

  • setCode() puede ser utilizado para establecer el código de respuesta HTTP que utilizar durante la redirección.

  • setExit() puede usarse para forzar un exit() tras una redirección. Por defecto es verdadero ( TRUE ).

  • setGotoSimple() puede ser utilizada para establecer la URL que usar por defecto si no se ha pasado ninguna a gotoSimple() . Utiliza la API de Zend_Controller_Action::_forward() : setGotoSimple($action, $controller = null, $module = null, array $params = array());

  • setGotoRoute() puede ser utilizada para establecer una URL basada en una ruta. Pasarla en un array de pares clave/valor y un nombre de ruta, y que ensamblarán la URL según la definición y el tipo de ruta.

  • setGotoUrl() puede ser utilizada para establecer una URL por defecto si no se pasa ninguna a gotoUrl() . Acepta un solo string URL .

  • setPrependBase() puede ser utilizada para anteponer la URL base del objeto solicitud a una URL especificada con setGotoUrl() , gotoUrl() , o gotoUrlAndExit() .

  • setUseAbsoluteUri() puede ser utilizada para forzar al Redirector a usar URI s absolutas cuando está redireccionando. Cuando se establece esta opción, se utiliza el valor de $_SERVER['HTTP_HOST'] , $_SERVER['SERVER_PORT'] , y $_SERVER['HTTPS'] para formar una URI completa a la URL especificada por uno de los métodos de redirección. Esta opción está desactivada por defecto, pero podrá ser activada por defecto en versiones posteriores.

Además, hay una variedad de métodos en el redireccionamiento para realizar las redirecciones actuales:

  • gotoSimple() usa setGotoSimple() ( _forward()-tipo API) para construir una URL y realizar un redireccionamiento.

  • gotoRoute() usa setGotoRoute() ( route-assembly ) para construir una URL y realizar un redireccionamiento.

  • gotoUrl() usa setGotoUrl() ( URL string ) para construir una URL y realizar un redireccionamiento.

Por último, usted puede determinar la redirección actual de la URL en cualquier momento usando getRedirectUrl() .

Ejemplos Básicos de Uso

Ejemplo #5 Estableciendo Opciones

Este ejemplo anula varias opciones, incluido el establecimiento del código de estado HTTP para usar en la redirección ('303'), no saliendo por defecto en la redirección, y definir una URL a usar por defecto cuando se redireccione.

class SomeController extends Zend_Controller_Action
     * Redirector - definido para completar el código
     * @var Zend_Controller_Action_Helper_Redirector
    protected $_redirector = null;

    public function init()
        $this->_redirector = $this->_helper->getHelper('Redirector');

        // Establece las opciones por defecto del redirector
        // Dado que el objeto es registrado en el ayudante, éstos pasan a
        // ser relevantes para todas las acciones desde este punto en adelante


    public function myAction()
        /* hacer algunas cosas */

        // Redireccionar a una URL previamente registrada,
        // y forzar una salida cuando esté hecho:
        return; // nunca alcanzado

Ejemplo #6 Usando Defaults

Este ejemplo asume que se usan los valores predeterminados, lo que significa que cualquier redirección resultará en un exit() inmediato.

class AlternativeController extends Zend_Controller_Action
     * Redirector - definido para completar el código
     * @var Zend_Controller_Action_Helper_Redirector
    protected $_redirector = null;

    public function init()
        $this->_redirector = $this->_helper->getHelper('Redirector');

    public function myAction()
        /* hacer algunas cosas */

        return; // nunca alcanzado dado que por defecto es ir a URL y salir

Ejemplo #7 Usando la API _forward() de goto()

La API gotoSimple() imita a la de Zend_Controller_Action::_forward() . La diferencia principal es que construye una URL desde los parámetros pasados, y utiliza el formato por defecto :module/:controller/:action/* del enrutador predeterminado. A continuación se redirecciona en lugar de encadenar la acción.

class ForwardController extends Zend_Controller_Action
     * Redirector - definido para completar el código
     * @var Zend_Controller_Action_Helper_Redirector
    protected $_redirector = null;

    public function init()
        $this->_redirector = $this->_helper->getHelper('Redirector');

    public function myAction()
        /* hacer algunas cosas */

        // Redireccionar a 'my-action' de 'my-controller' en el módulo
        // actual, usando los parámetros param1 => test y param2 => test2
                                       array('param1' => 'test',
                                             'param2' => 'test2'

Ejemplo #8 Usando Ruta de Ensamblaje con gotoRoute()

El siguiente ejemplo usa el método assemble() del enrutador para crear una URL basada en un array asociativo de parámetros pasados. Se supone que la siguiente ruta ha sido registrada:

$route = new Zend_Controller_Router_Route(
    array('controller' => 'archive',
          'module' => 'blog',
          'action' => 'view')
$router->addRoute('blogArchive', $route);

Dado un array con el año fijado a 2006, mes a 4, día a 24, e id a 42, entonces construye la siguiente URL /blog/2006/4/24/42 .

class BlogAdminController extends Zend_Controller_Action
     * Redirector - definido para completar el código
     * @var Zend_Controller_Action_Helper_Redirector
    protected $_redirector = null;

    public function init()
        $this->_redirector = $this->_helper->getHelper('Redirector');

    public function returnAction()
        /* hacer algunas cosas */

        // Redireccionar al archivo blog. Construir la siguiente URL:
        // /blog/2006/4/24/42
            array('year' => 2006,
                  'month' => 4,
                  'day' => 24,
                  'id' => 42),



El ayudante ViewRenderer está diseñado para satisfacer los siguientes objetivos:

  • Eliminar la necesidad de instanciar objetos de vista dentro de los controladores; los objetos de vista quedarán registrados automáticamente con el contralor.

  • Establece automáticamente el script de vista, el ayudante, y los paths de los filtros basados en el módulo actual. Asocia automáticamente el nombre del módulo actual como un prefijo de clase para las clases ayudante y filtro.

  • Crea un objeto de vista, disponible globalmente para todos los controladores y acciones despachados.

  • Permite al desarrollador establecer por defecto las opciones de renderizado para todos los controladores.

  • Agrega la capacidad para renderizar automáticamente los scripts de vista sin ninguna intervención.

  • Permite al desarrollador crear sus propias especificaciones para el path base de vistas y para el path de los scripts de vista.


Si realiza un _forward() , redirecciona, o render() manualmente, el autorendering no se llevará a cabo, como está realizando cualquiera de estas acciones le está diciendo al ViewRenderer que usted está determinando su propia salida.


El ViewRenderer está habilitado por defecto. Puede desactivarlo vía parámetro del front controller noViewRenderer ($front->setParam('noViewRenderer',true)) o eliminando al ayudante del stack de ayudantes ( Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer') ).

Si desea modificar los settings del ViewRenderer antes de despachar el front controller, puede hacerlo en una de las dos maneras:

  • Instanciar y registrar su propio objeto ViewRenderer y pasarlo al ayudante:

    $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
  • Inicializar y/o recuperar un objeto ViewRenderer por demanda via el ayudante:

    $viewRenderer =


En su uso más básico, simplemente instancie a ViewRenderer y páselo al ayudante de acciones. La forma más fácil para instanciar y registrar de una sola vez es utilizando el método del ayudante getStaticHelper() :


La primera vez que se instancia un controlador de acción, se disparará ViewRenderer para instanciar al objeto vista. Cada vez que el controlador es instanciado, se llama al método init() de ViewRenderer , que lo llevará a establecer la propiedad del controlador de acción, y llama a addScriptPath() con un path relativo al módulo actual; este será llamado con un prefijo de clase nombrada después del módulo actual, haciendo efectivamente el namespacing de todas las clases de ayudantes y filtros que define para el módulo.

Cad vez que llama a postDispatch() , este llamará a render() para la acción actual.

Como ejemplo, considere la siguiente clase:

// Una clase controlador, módulo foo:
class Foo_BarController extends Zend_Controller_Action
    // Render bar/index.phtml por defecto; no se requiere acción
    public function indexAction()

    // Render bar/populate.phtml con la variable 'foo' establecida a 'bar'.
    // Dado que el objeto vista está definido en preDispatch(),
    // ya está disponible.
    public function populateAction()
        $this->view->foo = 'bar';


// en uno de sus scripts de vista:
$this->foo(); // llama a Foo_View_Helper_Foo::foo()

El ViewRenderer también define una serie de accededores para permitir establecer y recuperar opciones de vista:

  • setView($view) le permite establecer el objeto vista para ViewRenderer . Se vuelve como una propiedad de clase pública $view .

  • setNeverRender($flag = true) puede ser utilizado para activar o desactivar globalmente el autorendering, es decir, para todos los controladores. Si es verdadero, postDispatch() no llamará automáticamente a render() en el controlador actual. getNeverRender() recupera el valor actual.

  • setNoRender($flag = true) puede ser utilizado para activar o desactivar el autorendering. Si es verdadero, postDispatch() no llamará automáticamente a render() en el controlador actual. Este ajuste se reseteará cada vez que se llame a preDispatch() (es decir, usted necesita establecer este flag para cada controlador para el cual no quiera que el autorenderering se ejecute). getNoRender() recupera el valor actual.

  • setNoController($flag = true) pude ser usado para decirle a render() que no busque el script de acción en un subdirectorio nombrado después de que el controlador (que es el comportamiento por defecto) getNoController() recupere el valor actual.

  • setNeverController($flag = true) es análogo a setNoController() , pero trabaja a un nivel global -- es decir, que no se reseteará por cada acción ejecutada. getNeverController() recupera el valor actual.

  • setScriptAction($name) puede ser utilizado para especificar el script de acción a renderizar. $name debe ser el nombre del script menos el sufijo del archivo (y sin el subdirectorio del controlador, a menos que noController se haya activado). Si no se ha especificado, busca un script de vista nombrado después de la acción en el objeto solicitud. getScriptAction() recupera el valor actual.

  • setResponseSegment($name) puede ser utilizado para especificar qué segmento del objeto respuesta nombrado renderizar. Si no se especifica, se hace en el segmento por defecto. getResponseSegment() recupera el valor actual.

  • initView($path, $prefix, $options) puede ser llamado para especificar el path base de las vistas, prefijos de clase para scripts de ayudantes y filtros, y las opciones de ViewRenderer . Puede pasar cualquiera de los siguientes flags: neverRender , noRender , noController , scriptAction , y responseSegment .

  • setRender($action = null, $name = null, $noController = false) le permite establecer cualquier scriptAction , responseSegment , y noController en un pase. direct() es un alias a este método, permitiéndole llamar a este método fácilmente dede su controlador:

    // Render 'foo' en lugar del script de acción actual
    // render form.phtml al segmento de respuesta de 'html', sin usar un
    // subdirectorio de scripts de controladores de acción:
    $this->_helper->viewRenderer('form', 'html', true);


    setRender() y direct() realmente no renderiza el script de vista, sino que establece indicaciones que postDispatch() y render() utlizarán para renderizar la vista.

El constructor le permite opcionalmente pasar el objeto vista y las opciones de ViewRenderer ; acepta los mismos flags que initView() :

$view    = new Zend_View(array('encoding' => 'UTF-8'));
$options = array('noController' => true, 'neverRender' => true);
$viewRenderer =
    new Zend_Controller_Action_Helper_ViewRenderer($view, $options);

Hay varios métodos adicionales para personalizar especificaciones del path, usados para determinar el path base del script de vista para añadir al objeto vista, y el path del script de vista a usar cuando esté autodeterminando el script de vista a renderizar. Cada uno de estos métodos toma uno o más de los siguientes localizadores:

  • :moduleDir hace referencia a la actual directorio base del módulo(por convención, el directorio padre del directorio del módulo controlador).

  • :module hace referencia al nombre del módulo actual.

  • :controller hace referencia al nombre del controlador actual.

  • :action hace referencia al nombre de la acción actual.

  • :suffix hace referencia al sufijo del script de vista (que puede ser definido via setViewSuffix() ).

Los métodos para controlar las especificaciones del path son:

  • setViewBasePathSpec($spec) le permite cambiar la especificación del path utilizada para determinar el path base para añadir al objeto vista. La especificación por defecto es :moduleDir/views . Puede recuperar la especificación actual en cualquier momento usando getViewBasePathSpec() .

  • setViewScriptPathSpec($spec) le permite cambiar el path de la especificación utilizada para determinar el path a un script de vista individual (menos el path de la base del script de vista). La especificación por defecto es :controller/:action.:suffix . Puede recuperar la especificación actual en cualquier momento usando getViewScriptPathSpec() .

  • setViewScriptPathNoControllerSpec($spec) le permite cambiar el path de la especificación utilizado para determinar el path a un script de vista individual cuando noController está activado (menos el path base del script de vista). La especificación por defecto es :action.:suffix . Puede recuperar la especificación actual en cualquier momento usando getViewScriptPathNoControllerSpec() .

Para un control más refinado sobre el path de especificaciones, puede usar Zend_Filter_Inflector . Bajo el capó, ViewRenderer ya usa un inflector para realizar mapeos del path. Para interactuar con el inflector -- ya sea para establecerlo para uso propio, o para modificar el inflector por defecto, se pueden utilizar los siguientes métodos:

  • getInflector() recupera el inflector. Si no existe todavía en ViewRenderer , se crea uno utilizando las reglas predeterminadas.

    Por defecto, utiliza reglas de referencias estáticas para el sufijo y directorio de módulos, así como una meta estática; esto permite que diversas propiedades de ViewRenderer tengan la capacidad de modificar dinámicamente al inflector.

  • setInflector($inflector, $reference) permite establecer un inflector personalizado para usar con ViewRenderer . Si $reference es verdadero, establecerá el sufijo y directorio de módulos como referencias estáticas a las propiedades de ViewRenderer , así como al objetivo.

Nota: Convenciones por Defecto para Lookup

El ViewRenderer hace algún tipo de normalización del path para facilitar la búsqueda de los scripts de vista. Las reglas predeterminadas son los siguientes:

  • :module : MixedCase y camelCasedWords están separados por guiones, y el string completo se convierte a minúsculas. Por ejemplo: "FooBarBaz" pasa a ser "foo-bar-baz".

    Internamente, el inflector utiliza los filtros Zend_Filter_Word_CamelCaseToDash y Zend_Filter_StringToLower .

  • :controller : MixedCase y camelCasedWords están separados por guiones; los subrayados se convierten en separadores de directorio , y el string emitido a minúsculas. Ejemplos: " FooBar " pasa a ser "foo-bar"; " FooBar_Admin " pasa a ser " foo-bar/admin ".

    Internamente, el inflector utiliza los filtros Zend_Filter_Word_CamelCaseToDash , Zend_Filter_Word_UnderscoreToSeparator , y Zend_Filter_StringToLower .

  • :action : MixedCase y camelCasedWords están separados por guiones; los caracteres no alfanuméricos son traducidos a guiones, y el string emitido a minúsculas. Ejemplos: "fooBar" pasa a ser "foo-bar"; "foo-barBaz" pasa a ser "foo-bar-baz".

    Internamente, el inflector utiliza los filtros Zend_Filter_Word_CamelCaseToDash , Zend_Filter_PregReplace , y Zend_Filter_StringToLower .

Los últimos temas en la API de ViewRenderer son los métodos para determinar realmente los paths de los scripts de vista y el rendering de las vistas. Estos incluyen:

  • renderScript($script, $name) permite renderizar un script con una ruta que especifique, opcionalmente a un segmento nombrado del path. Cuando se utiliza este método, ViewRenderer no autodetermina el nombre del script, en cambio pasa directamente a $script el argumento directamente al método del objeto vista render() .


    Una vez que la vista ha sido renderizada al objeto respuesta, se establece noRender para evitar accidentalmente renderizar el mismo script de vista varias veces.


    Por defecto, Zend_Controller_Action::renderScript() le delega a ViewRenderer el método renderScript() .

  • getViewScript($action, $vars) crea el path a un script de vista basado en la acción pasada y/o cualquier variables pasadas en $vars . Las claves para este array pueden incluir cualquiera de las claves de especificación de paths ('moduleDir', 'module', 'controller', 'action', y 'suffix'). Se utilizarán cualquiera de la variables pasadas; de lo contrario, se utilizarán valores basados en la petición actual.

    getViewScript() utilizará tanto a viewScriptPathSpec o viewScriptPathNoControllerSpec sobre la base establecida del flag noController .

    Los delimitadores de palabras encontrados en un módulo, controlador o nombres de acción serán reemplazados por guiones ('-'). Así pues, si tiene el nombre de controlador ' ' y la acción ' baz:bat ', utilizando la especificación por defecto del path se traducirá en un path al script de vista ' foo-bar/baz-bat.phtml '.


    Por defecto, Zend_Controller_Action::getViewScript() delega el método getViewScript() de ViewRenderer .

  • render($action, $name, $noController) comprueba primero para ver si bien $name o $noController se han pasado, y si es así, establece los flags apropiados (responseSegment y noController, respectivamente) en ViewRenderer . A continuación, pasa el argumento $action , si hay alguno, a getViewScript() . Por último, pasa el path calculado del script de vista a renderScript() .


    Hay que ser conscientes de los efectos secundarios al usar render() : los valores que usted pasa para el nombre del segmento respuesta y para el flag noController persistirán en el objeto. Además, noRender será establecido después de completar la renderización.


    Por defecto, Zend_Controller_Action::render() delega a ViewRenderer el método render() .

  • renderBySpec($action, $vars, $name) permite pasar variables de especificación del path a fin de determinar el path para la creación del script de vista. Este pasa $action y $vars a getScriptPath() , y luego pasa el path del script resultante y $name a renderScript() .

Ejemplos Uso Básico

Ejemplo #9 Uso Básico

En lo más básico, usted simplemente inicializa y registra el ayudante ViewRenderer con el ayudante broker en su bootstrap, y luego establecer las variables en sus métodos de acción.

// En su bootstrap:


// 'foo' módulo, 'bar' controlador:
class Foo_BarController extends Zend_Controller_Action
    // Render bar/index.phtml por defecto; no se requieren acciones
    public function indexAction()

    // Render bar/populate.phtml la variable 'foo' establecida a 'bar'.
    // Dado que el objeto fue definido en preDispatch(), está disponible.
    public function populateAction()
        $this->view->foo = 'bar';

    // No hace rendering, ya que salta a otra acción; la nueva acción
    // realizará cualquier rendering
    public function bazAction()

    // No hace rendering, ya que redirecciona a otra ubicación
    public function batAction()

Nota: Convenciones de Nombres: Delimitadores de Palabras en Controladores y Nombres de Acción

Si su controlador o nombre de acción está compuesto por varias palabras, el despachador exige que estos sean separados de la URL por un path específico y caracteres delimitadores de palabras. El ViewRenderer reemplaza cualquier delimitador de paths encontrado en el nombre del controlador con el delimitador actual ('/'), y cualquier delimitador de palabra encontrado con un guión ('-') cuando crea paths. Así, una llamada a la acción / despachará a FooBarController::bazBatAction() en FooBarController.php , el cual renderizaría a foo-bar/baz-bat.phtml ; una llamada a la acción /bar_baz/baz-bat despachará a Bar_BazController::bazBatAction() en Bar/BazController.php (note la separación del path) y renderiza bar/baz/baz-bat.phtml .

Tener en cuenta que el en el segundo ejemplo, el módulo es todavía el módulo por defecto, pero que, debido a la existencia de un separador de paths, el controlador recibe el nombre Bar_BazController , en Bar/BazController.php . El ViewRenderer imita la jerarquía del directorio del controlador.

Ejemplo #10 Deshabilitando Autorender

Para algunas acciones o controladores, usted puede querer apagar el autorendering -- por ejemplo, si quiere emitir un tipo diferente de salida ( XML , JSON , etc), o si simplemente no desea emitir nada. Tiene dos opciones: apagar todos los casos de autorendering ( setNeverRender() ), o simplemente desactivarlo para la acción actual ( setNoRender() ).

// Baz clase del controlador, bar módulo:
class Bar_BazController extends Zend_Controller_Action
    public function fooAction()
        // No auto renderize esta acción

// Bat clase del controlador, bar módulo:
class Bar_BatController extends Zend_Controller_Action
    public function preDispatch()
        // Nunca auto renderizar las acciones de este controlador


En muchos casos, no tiene sentido desactivar el autorendering globalmente (ala setNeverRender() ), y la única cosa que puede ganar de ViewRenderer es el autosetup del objeto de vista.

Ejemplo #11 Eligiendo Un Script de Vista Diferente

Algunas situaciones requieren renderizar un script diferente al llamado después de la acción. Por ejemplo, si tiene un controlador que tiene tanto las acciones de agregar y de editar, ambos pueden mostrar la misma vista 'form', aunque con diferentes valores establecidos. Puede cambiar fácilmente el nombre del script usado tanto con setScriptAction() , setRender() , o llamando al ayudante como un método, que invocará a setRender() .

// Bar clase controlador, foo módulo:
class Foo_BarController extends Zend_Controller_Action
    public function addAction()
        // Render 'bar/form.phtml' en lugar de 'bar/add.phtml'

    public function editAction()
        // Render 'bar/form.phtml' en lugar de 'bar/edit.phtml'

    public function processAction()
        // hacer alguna validación...
        if (!$valid) {
            // Render 'bar/form.phtml' en lugar de 'bar/process.phtml'

        // de otra manera, continuar procesando...


Ejemplo #12 Modificando la Vista Registrada

¿Y si se necesita modificar el objeto vista -- por ejemplo, cambiar el ayudante de paths, o la codificación?. Puede hacerlo ya sea por modificar el objeto vista establecido en su controlador, o arrebatándole el objeto vista a ViewRenderer ; ambas son referencias al mismo objeto.

// Bar clase controlador, foo módulo:
class Foo_BarController extends Zend_Controller_Action
    public function preDispatch()
        // cambiar la codificavión de la vista

    public function bazAction()
        // Obtener el objeto vista y establecer
        // el callback de escape a 'htmlspecialchars'
        $view = $this->_helper->viewRenderer->view;

Ejemplos de Uso Avanzado

Ejemplo #13 Cambiando las Especificaciones del Path

En algunas circunstancias, puede decidir que las especificaciones del path por defecto no se adaptan a su sitio. Por ejemplo, usted puede querer tener un árbol único de plantillas al que puede dar acceso a sus diseñadores (esto es muy típico cuando se utiliza » Smarty , por ejemplo). En ese caso, puede querer embeber los datos de la especificación del path base de la vista, y crear una especificación alternativa para el script de vista del path ellos mismos.

Para los fines de este ejemplo, supongamos que el path base de las vistas debería ser ' /opt/vendor/templates ', y que desea para que los scripts de vista sean referenciados por ' :moduleDir/:controller/:action.:suffix '; si el flag noController ha sido establecido, quiere renderizar fuera del nivel superior en lugar de en un subdirectorio ( ':action.:suffix '). Por último, que quiere utilizar 'tpl' como el sufijo del nombre de archivo del script de vista.

 * En su bootstrap:

// Implementación de una vista diferente
$view = new ZF_Smarty();

$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);

Ejemplo #14 Rendering Múltiples Scripts de Vista desde una Sola Acción

A veces, puede que necesite renderizar múltiples scripts de vista desde una sola acción. Esto es muy sencillo -- simplemente hacer múltiples llamadas a render() :

class SearchController extends Zend_Controller_Action
    public function resultsAction()
        // Suponga que $this->model es el modelo actual
        $this->view->results =
            $this->model->find($this->_getParam('query', '');

        // render() por defecto lo delega al ViewRenderer
        // Render primero al from de búsqueda y luego los resultados

    public function formAction()
        // No hacer nada; ViewRenderer hace autorender del script de vista

Writing Your Own Helpers

Action helpers extend Zend_Controller_Action_Helper_Abstract, an abstract class that provides the basic interface and functionality required by the helper broker. These include the following methods:

  • setActionController() is used to set the current action controller.

  • init(), triggered by the helper broker at instantiation, can be used to trigger initialization in the helper; this can be useful for resetting state when multiple controllers use the same helper in chained actions.

  • preDispatch(), is triggered prior to a dispatched action.

  • postDispatch() is triggered when a dispatched action is done -- even if a preDispatch() plugin has skipped the action. Mainly useful for cleanup.

  • getRequest() retrieves the current request object.

  • getResponse() retrieves the current response object.

  • getName() retrieves the helper name. It retrieves the portion of the class name following the last underscore character, or the full class name otherwise. As an example, if the class is named Zend_Controller_Action_Helper_Redirector, it will return Redirector; a class named FooMessage will simply return itself.

You may optionally include a direct() method in your helper class. If defined, it allows you to treat the helper as a method of the helper broker, in order to allow easy, one-off usage of the helper. As an example, the redirector defines direct() as an alias of goto(), allowing use of the helper like this:

// Redirect to /blog/view/item/id/42
$this->_helper->redirector('item', 'view', 'blog', array('id' => 42));

Internally, the helper broker's __call() method looks for a helper named redirector, then checks to see if that helper has a defined direct() method, and calls it with the arguments provided.

Once you have created your own helper class, you may provide access to it as described in the sections above.

Previous Next
Introducción a Zend Framework
Descripción general
Aprendiendo Zend Framework
Inicio Rápido con Zend Framework
Zend Framework & MVC Introduction
Create Your Project
Create A Layout
Create a Model and Database Table
Create A Form
Autocarga o Carga automática en Zend Framework
Goals and Design
Basic Autoloader Usage
Resource Autoloading
Plugins en Zend Framework
Using Plugins
Primeros pasos con Zend_Layout
Using Zend_Layout
Zend_Layout: Conclusions
Introducción a Zend_View Placeholders
Basic Placeholder Usage
Standard Placeholders
View Placeholders: Conclusion
Comprensión y uso de Zend Form Decorators
Decorator Basics
Layering Decorators
Rendering Individual Decorators
Creating and Rendering Composite Elements
Primeros pasos con Zend_Session, Zend_Auth, and Zend_Acl
Building Multi-User Applications With Zend Framework
Managing User Sessions In ZF
Authenticating Users in Zend Framework
Building an Authorization System in Zend Framework
Primeros pasos con Zend_Search_Lucene
Zend_Search_Lucene Introduction
Lucene Index Structure
Index Opening and Creation
Supported queries
Search result pagination
Primeros pasos con Zend_Paginator
Simple Examples
Pagination Control and ScrollingStyles
Putting it all Together
Referencia de Zend Framework
Perfeccionamiento de los controles de acceso
Uso Avanzado
Inicio rápido con Zend_Application
Teoría de Operación
Funcionalidad Básica
Plugins de Recursos Disponibles
Tabla de base de datos de autenticación
Autenticación "Digest"
Adaptador de Autenticación HTTP
LDAP Authentication
Autenticación con Open ID
Barcode creation using Zend_Barcode class
Zend_Barcode Objects
Zend_Barcode Renderers
The Theory of Caching
Zend_Cache Frontends
Zend_Cache Backends
The Cache Manager
Captcha Operation
CAPTCHA Adapters
Ejemplos de Zend_CodeGenerator
Referencias de Zend_CodeGenerator
Aspectos Teóricos
Declaring Getopt Rules
Fetching Options and Arguments
Configuring Zend_Console_Getopt
Inicio rápido a Zend_Controller
Conceptos Básicos de Zend_Controller
El Front Controller
La solicitud del Objeto
El Router Standard
El Despachador
Controladores de Acción
Action Helpers
The Response Object
Using a Conventional Modular Directory Structure
Excepciones MVC
Introduction to Zend_Currency
Using Zend_Currency
Options for currencies
What makes a currency?
Where is the currency?
How does the currency look like?
How much is my currency?
Calculating with currencies
Exchanging currencies
Additional informations on Zend_Currency
Theory of Operation
Basic Methods
Zend_Date API Overview
Creation of Dates
Constants for General Date Functions
Working Examples
Zend_Db_Table Relationships
Mostrar información de variables(Dumping Variables)
Zend_Dojo_Data: Envolturas de
Ayudantes de Dojo View
Elementos y Decoradores de Dojo Form
Zend_Dojo build layer support
Uso de Excepciones
Basic usage
Previous Exceptions
Importing Feeds
Retrieving Feeds from Web Pages
Consuming an RSS Feed
Consuming an Atom Feed
Consuming a Single Atom Entry
Modifying Feed and Entry structures
Custom Feed and Entry Classes
Validators for Zend_File_Transfer
Filters for Zend_File_Transfer
Standard Filter Classes
Filter Chains
Writing Filters
Inicio rápido a Zend_Form
Creando elementos de formulario usando Zend_Form_Element
Creando formularios usando Zend_Form
Creando un personalizado marcado de formulario usando Zend_Form_Decorator
Elementos Enviados en el Formulario Estandard de Zend Framework
Decoradores de Formulario (Form Decorartors) estándar contenidos en Zend Framework
Internacionalización de Zend_Form
Uso avanzado de Zend_Form
Authenticating with AuthSub
Using the Book Search Data API
Authenticating with ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Health
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Using Picasa Web Albums
Using the YouTube Data API
Catching Gdata Exceptions
Zend_Http_Client - Advanced Usage
Zend_Http_Client - Connection Adapters
Zend_Http_Cookie and Zend_Http_CookieJar
Uso Básico
Uso Avanzado de Zend_Json
Conversión de XML a JSON
Zend_Json_Server - servidor JSON-RPC
Zend_Layout Quick Start
Zend_Layout Configuration Options
Zend_Layout Advanced Usage
API overview
Usage Scenarios
Object oriented access to the LDAP tree using Zend_Ldap_Node
Getting information from the LDAP server
Serializing LDAP data to and from LDIF
Cargando archivos y clases dinámicamente
The Autoloader
Resource Autoloaders
Loading Plugins
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported locales
Using the Factory to Create a Log
Sending via SMTP
Sending Multiple Mails per SMTP Connection
Using Different Transports
Adding Recipients
Controlling the MIME Boundary
Additional Headers
Character Sets
SMTP Authentication
Securing SMTP Transport
Reading Mail Messages
Getting Started With Zend_Markup
Zend_Markup Parsers
Zend_Markup Renderers
Creation of Measurements
Outputting measurements
Manipulating Measurements
Types of measurements
Memory Manager
Memory Objects
Introduction to OAuth
Zend_OpenId_Consumer Basics
Advanced usage
Creando y Cargando Documentos PDF
Guardar Cambios a Documentos PDF
Trabajando con Páginas
Interactive Features
Información del Documento y Metadatos
Ejemplo de Uso del módulo Zend_Pdf
Example usage
Customizing Zend_Queue
Zend_Reflection Examples
Zend_Reflection Reference
Using the Registry
Building Indexes
Searching an Index
Query Language
Query Construction API
Character Set
Interoperating with Java Lucene
Best Practices
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Storage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Basic Usage
Advanced Usage
Global Session Management
WSDL Accessor
Working with Zend_TimeSync
Using Zend_Tool On The Command Line
Extending Zend_Tool
Usando la herramienta CLI
Creando Proveedores para usar con Zend_Tool_Framework
Shipped System Providers
Extending and Configuring Zend_Tool_Framework
Create A Project
Zend_Tool Project Providers
Zend_Tool_Project Internos
Adapters for Zend_Translate
Using Translation Adapters
Creating source files
Additional features for translation
Plural notations for Translation
Clases de Validación Estándar
Cadenas de Validadores
Escribiendo Validadores
Validation Messages
Obteniendo la versión de Zend Framework Version
Controller Scripts
View Scripts
View Helpers
ZendX_JQuery View Helpers
ZendX_JQuery Form Elements and Decorators
Requisitos de Zend Framework
Versión de PHP
Extensiones de PHP
Componentes de Zend Framework
Dependencias de Zend Framework
Notas de Migración de Zend Framework
Zend Framework 1.10
Zend Framework 1.9
Zend Framework 1.8
Zend Framework 1.7
Zend Framework 1.6
Zend Framework 1.5
Zend Framework 1.0
Zend Framework 0.9
Zend Framework 0.8
Zend Framework 0.6
Estándares de codificación de Zend Framework para PHP
Formato de archivos PHP
Convenciones de Nombres
Estilo de código
Zend Framework Documentation Standard
Documentation File Formatting
Recommended Project Structure for Zend Framework MVC Applications
Recommended Project Directory Structure
Module Structure
Rewrite Configuration Guide
Guía de Rendimiento de Zend Framework
Class Loading
Zend_Db Performance
Internationalization (i18n) and Localization (l10n)
View Rendering
Copyright Information