Dojo does not have an AutoCompletion widget per se, but has two widgets that can perform AutoCompletion: ComboBox and FilteringSelect. In both cases, they require a data store that implements the QueryReadStore; for more information on these topics, see the » dojo.data documentation.

In Zend Framework, you can pass a simple indexed array to the AutoCompleteDojo helper, and it will return a JSON response suitable for use with such a store:

<?php
// within a controller action:
$this->_helper->autoCompleteDojo($data);

dojo.provide("custom.TestNameReadStore");
dojo.declare("custom.TestNameReadStore", dojox.data.QueryReadStore, {
    fetch:function (request) {
        request.serverQuery = { test:request.query.name };
        return this.inherited("fetch", arguments);
    }
});

<?php
class TestController extends Zend_Controller_Action
{
    protected $_form;

    public function getForm()
    {   
        if (null === $this->_form) {
            require_once 'Zend/Form.php';
            $this->_form = new Zend_Form();
            $this->_form->setMethod('get')
                ->setAction($this->getRequest()->getBaseUrl() . '/test/process')
                ->addElements(array(
                    '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;
    }
}

<?php
class TestController extends Zend_Controller_Action
{
    // ...

    /**
     * Landing page
     */
    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;
            }
        }
        $this->_helper->autoCompleteDojo($matches);
    }
}

<? // setup our data store: ?>
<div dojoType="custom.TestNameReadStore" jsId="testStore"
    url="<?= $this->baseUrl() ?>/unit-test/autocomplete/format/ajax" requestMethod="get"></div>

<? // render our form: ?>
<?= $this->form ?>

<? // setup Dojo-related CSS to load in HTML head: ?>
<? $this->headStyle()->captureStart() ?>
@import "<?= $this->baseUrl() ?>/javascript/dijit/themes/tundra/tundra.css";
@import "<?= $this->baseUrl() ?>/javascript/dojo/resources/dojo.css";
<? $this->headStyle()->captureEnd() ?>

<? // setup javascript to load in HTML head, including all required Dojo
   // libraries: ?>
<? $this->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("dojox.data.QueryReadStore");
dojo.require("dijit.form.ComboBox");
dojo.require("custom.TestNameReadStore");
<? $this->headScript()->captureEnd() ?>

» Scriptaculous expects an HTML response in a specific format.

The helper to use with this library is 'AutoCompleteScriptaculous'. Simply provide it an array of data, and the helper will create an HTML response compatible with Ajax.Autocompleter.

By default, two contexts are available to the ContextSwitch helper: json and xml.

• JSON. The JSON context sets the 'Content-Type' response header to 'application/json', and the view script suffix to 'json.phtml'.

  By default, however, no view script is required. It will simply serialize all view variables, and emit the JSON response immediately.

  This behaviour can be disabled by turning off auto-JSON serialization:

  <?php
  $this->_helper->contextSwitch()->setAutoJsonSerialization(false);
  ?>

• XML. The XML context sets the 'Content-Type' response header to 'text/xml', and the view script suffix to 'xml.phtml'. You will need to create a new view script for the context.

Sometimes, the default contexts are not enough. For instance, you may wish to return YAML, or serialized PHP, an RSS or ATOM feed, etc. ContextSwitch allows you to do so.

The easiest way to add a new context is via the addContext() method. This method takes two arguments, the name of the context, and an array specification. The specification should include one or more of the following:

• suffix: the suffix to prepend to the default view suffix as registered in the ViewRenderer.

• headers: an array of header/value pairs you wish sent as part of the response.

• callbacks: an array containing one or more of the keys 'init' or 'post', pointing to valid PHP callbacks that can be used for context initialization and post processing.

  Initialization callbacks occur when the context is detected by ContextSwitch. You can use it to perform arbitrary logic that should occur. As an example, the JSON context uses a callback to disable the ViewRenderer when auto-JSON serialization is on.

  Post processing occurs during the action's postDispatch() routine, and can be used to perform arbitrary logic. As an example, the JSON context uses a callback to determine if auto-JSON serialization is on; if so, it serializes the view variables to JSON and sends the response, but if not, it re-enables the ViewRenderer.

There are a variety of methods for interacting with contexts:

• addContext($context, array $spec): add a new context. Throws an exception if the context already exists.

• setContext($context, array $spec): add a new context or overwrite an existing context. Uses the same specification as addContext().

• addContexts(array $contexts): add many contexts at once. The $contexts array should be an array of context/specification pairs. If any of the contexts already exists, it will throw an exception.

• setContexts(array $contexts): add new contexts and overwrite existing ones. Uses the same specification as addContexts().

• hasContext($context): returns true if the context exists, false otherwise.

• getContext($context): retrieve a single context by name. Returns an array following the specification used in addContext().

• getContexts(): retrieve all contexts. Returns an array of context/specification pairs.

• removeContext($context): remove a single context by name. Returns true if successful, false if the context was not found.

• clearContexts(): remove all contexts.

There are two mechanisms for setting available contexts. You can either manually create arrays in your controller, or use several methods in ContextSwitch to assemble them.

The principle method for adding action/context relations is addActionContext(). It expects two arguments, the action to which the context is being added, and either the name of a context or an array of contexts. As an example, consider the following controller class:

<?php
class FooController extends Zend_Controller_Action
{
    public function listAction()
    {
    }

    public function viewAction()
    {
    }

    public function commentsAction()
    {
    }

    public function updateAction()
    {
    }
}
?>

Let's say we wanted to add an XML context to the 'list' action, and XML and JSON contexts to the 'comments' action. We could do so in the init() method:

<?php
class FooController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper->contextSwitch()
             ->addActionContext('list', 'xml')
             ->addActionContext('comments', array('xml', 'json'))
             ->initContext();
    }
}
?>

Alternately, you could simply define the array property $contexts:

<?php
class FooController extends Zend_Controller_Action
{
    public $contexts = array(
        'list'     => array('xml'),
        'comments' => array('xml', 'json')
    );

    public function init()
    {
        $this->_helper->contextSwitch()->initContext();
    }
}
?>

The above is less overhead, but also prone to potential errors.

The following methods can be used to build the context mappings:

• addActionContext($action, $context): marks one or more contexts as available to an action. If mappings already exists, simply appends to those mappings. $context may be a single context, or an array of contexts.

  A value of true for the context will mark all available contexts as available for the action.

  An empty value for $context will disable all contexts for the given action.

• setActionContext($action, $context): marks one or more contexts as available to an action. If mappings already exists, it replaces them with those specified. $context may be a single context, or an array of contexts.

• addActionContexts(array $contexts): add several action/context pairings at once. $contexts should be an associative array of action/context pairs. It proxies to addActionContext(), meaning that if pairings already exist, it appends to them.

• setActionContexts(array $contexts): acts like addActionContexts(), but overwrites existing action/context pairs.

• hasActionContext($action, $context): determine if a particular action has a give context.

• getActionContexts($action = null): returns either all contexts for a given action, or all action/context pairs.

• removeActionContext($action, $context): remove one or more contexts from a given action. $context may be a single context or an array of contexts.

• clearActionContexts($action = null): remove all contexts from a given action, or from all actions with contexts.

To initialize context switching, you need to call initContext() in your action controller:

<?php
class NewsController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper->contextSwitch()->initContext();
    }
}
?>

In some cases, you may want to force the context used; for instance, you may only want to allow the XML context if context switching is activated. You can do so by passing the context to initContext():

<?php
$contextSwitch->initContext('xml');
?>

A variety of methods can be used to alter the behaviour of the ContextSwitch helper. These include:

• setAutoJsonSerialization($flag): By default, JSON contexts will serialize any view variables to JSON notation and return this as a response. If you wish to create your own response, you should turn this off; this needs to be done prior to the call to initContext().

  <?php
  $contextSwitch->setAutoJsonSerialization(false);
  $contextSwitch->initContext();
  ?>

  You can retrieve the value of the flag with getAutoJsonSerialization().

• setSuffix($context, $suffix, $prependViewRendererSuffix): With this method, you can specify a different suffix to use for a given context. The third argument is used to indicate whether or not to prepend the current ViewRenderer suffix with the new suffix; this flag is enabled by default.

  Passing an empty value to the suffix will cause only the ViewRenderer suffix to be used.

• addHeader($context, $header, $content): Add a response header for a given context. $header is the header name, and $content is the value to pass for that header.

  Each context can have multiple headers; addHeader() adds additional headers to the context's header stack.

  If the $header specified already exists for the context, an exception will be thrown.

• setHeader($context, $header, $content): setHeader() acts just like addHeader(), except it allows you to overwrite existing context headers.

• addHeaders($context, array $headers): Add multiple headers at once to a given context. Proxies to addHeader(), so if the header already exists, an exception will be thrown. $headers is an array of header/context pairs.

• setHeaders($context, array $headers.): like addHeaders(), except it proxies to setHeader(), allowing you to overwrite existing headers.

• getHeader($context, $header): retrieve the value of a header for a given context. Returns null if not found.

• removeHeader($context, $header): remove a single header for a given context.

• clearHeaders($context, $header): remove all headers for a given context.

• setCallback($context, $trigger, $callback): set a callback at a given trigger for a given context. Triggers may be either 'init' or 'post' (indicating callback will be called at either context initialization or postDispatch). $callback should be a valid PHP callback.

• setCallbacks($context, array $callbacks): set multiple callbacks for a given context. $callbacks should be trigger/callback pairs. In actuality, the most callbacks that can be registered are two, one for initialization and one for post processing.

• getCallback($context, $trigger): retrieve a callback for a given trigger in a given context.

• getCallbacks($context): retrieve all callbacks for a given context. Returns an array of trigger/callback pairs.

• removeCallback($context, $trigger): remove a callback for a given trigger and context.

• clearCallbacks($context): remove all callbacks for a given context.

• setContextParam($name): set the request parameter to check when determining if a context switch has been requested. The value defaults to 'format', but this accessor can be used to set an alternate value.

  getContextParam() can be used to retrieve the current value.

• setAutoDisableLayout($flag): By default, layouts are disabled when a context switch occurs; this is because typically layouts will only be used for returning normal responses, and have no meaning in alternate contexts. However, if you wish to use layouts (perhaps you may have a layout for the new context), you can change this behaviour by passing a true value to setAutoDisableLayout(). You should do this before calling initContext().

  To get the value of this flag, use the accessor getAutoDisableLayout().

• getCurrentContext() can be used to determine what context was detected, if any. This returns null if no context switch occurred, or if called before initContext() has been invoked.

The AjaxContext helper extends ContextSwitch, so all of the functionality listed for ContextSwitch is available to it. There are a few key differences, however.

First, it uses a different action controller property for determining contexts, $ajaxable. This is so you can have different contexts used for AJAX versus normal HTTP requests. The various *ActionContext*() methods of AjaxContext will write to this property.

Second, it will only trigger if an XmlHttpRequest has occurred, as determined by the request object's isXmlHttpRequest() method. Thus, if the context parameter ('format') is passed in the request, but the request was not made as an XmlHttpRequest, no context switch will trigger.

Third, AjaxContext adds an additional context, HTML. In this context, it sets the suffix to 'ajax.phtml' in order to differentiate the context from a normal request. No additional headers are returned.

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

    public function viewAction()
    {
        // Pull a single comment to view.
        // When AjaxContext detected, uses the comment/view.ajax.phtml 
        // view script.
    }

    public function formAction()
    {
        // Render the "add new comment" form.
        // When AjaxContext detected, uses the comment/form.ajax.phtml 
        // view script.
    }

    public function processAction()
    {
        // Process a new comment
        // Return the results as JSON; simply assign the results as view
        // variables, and JSON will be returned.
    }
}
?>

L'aide FlashMessenger vous permet de fournir les messages dont l'utilisateur pourrait avoir besoin dans la requête suivante. Pour accomplir ceci, FlashMessenger utilise Zend_Session_Namespace pour stocker les messages à retrouver dans la prochaine requête. C'est généralement une bonne idée si vous planifiez d'utiliser Zend_Session ou Zend_Session_Namespace, que vous initialisez avec Zend_Session::start() dans votre fichier d'amorçage. (Reportez vous à la documentation de Zend_Session pour plus de détails sur son utilisation.)

L'exemple ci-dessous vous montre l'utilisation du flash messenger dans sa forme la plus basique. Quand l'action /some/my est appelée, il ajoute le message "Record Saved!". Une requête suivante vers l'action /some/my-next-request le retouvera (ainsi que le détruira).

<?php
class SomeController extends Zend_Controller_Action
{
    /**
     * FlashMessenger
     *
     * @var Zend_Controller_Action_Helper_FlashMessenger
     */
    protected $_flashMessenger = null;

    public function init()
    {
        $this->_flashMessenger = $this->_helper->getHelper('FlashMessenger');
        $this->initView();
    }

    public function myAction()
    {
        /**
         * Méthode par défaut por obtenir l'instance de
         * Zend_Controller_Action_Helper_FlashMessenger à la demande
         */
        $this->_flashMessenger->addMessage('Record Saved!');
    }

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

L'aide Redirector vous permet d'utiliser un objet de redirection qui remplit tous les besoins de votre application nécessaire à une redirection vers une nouvelle URL. Il fournit de nombreux avantages par rapport à la méthode _redirect(), comme la capacité de préconfigurer le comportement du site dans l'objet redirector ou d'utiliser l'interface intégrée goto($action, $controller, $module, $params) similaire à Zend_Controller_Action::_forward().

Redirector possède une certain nombre de méthodes qui peuvent être utilisées pour affecter le comportement de la redirection :

• setCode() peut être utilisée pour paramètrer le code HTTP de la réponse à utiliser pendant la redirection.

• setExit() peut être utilisée pour forcer un exit() juste après la redirection. Par défaut ceci vaut true.

• setGoto() peut être utilisée pour paramètrer l'URL par défaut à utiliser si aucune n'est fournie à goto(). Elle utilise les API de Zend_Controller_Action::_forward() : setgoto($action, $controller = null, $module = null, array $params = array());

• setGotoRoute() peut être utilisée pour paramètrer une URL basée sur une route enregistrée. Fournissez un tableau de paires clé/valeur et une route nommée, et elle assemblera une URL suivant le type de la route et sa définition.

• setGotoUrl() peut être utilisée pour paramètrer l'URL par défaut à utiliser si aucune n'est fournie à gotoUrl(). Accepte une chaîne unique correspondant à une URL.

• setPrependBase() peut être utilisée pour ajouter une chaîne au début de l'URL de base de l'objet requête pour les URLs spécifiées avec setGotoUrl(), gotoUrl(), ou gotoUrlAndExit().

• setUseAbsoluteUri() peut être utilisée pour forcer le Redirector à utiliser des URI absolus pour la redirection. Quand cette option est choisie, elle utilise les valeurs de $_SERVER['HTTP_HOST'], $_SERVER['SERVER_PORT'], et $_SERVER['HTTPS'] pour former un URI complet à partir de l'URL spécifiée par une des méthodes de redirection. Cette option est inactive par défaut, mais pourra être activée par défaut dans les prochaines releases.

De plus, il y a une variété de méthodes dans le redirector pour réaliser les redirections actuelles :

• goto() utilise setGoto() (API de type _forward()) pour construire une URL et réaliser une redirection.

• gotoRoute() utilise setGotoRoute() (assemblage de route) pour construire une URL et réaliser une redirection.

• gotoUrl() utilise setGotoUrl() (URL sous forme de chaîne) pour construire une URL et réaliser une redirection.

Enfin, vous pouvez déterminer l'URL de la redirection courante à tout moment en utilisant getRedirectUrl().

L'aide ViewRenderer apporte les comportements suivants :

• Elimine le besoin d'instancier un objet de vue dans ses contrôleurs. Ceci devient automatique.

• Configure automatiquement les chemins vers les scripts de vue, les aides, et les filtres, en se basant sur le module actuel et associe le nom du module comme préfixe de classe pour les aides et les filtres.

• Créer un objet de vue général accessible pour tous les contrôleurs et donc pour toutes les actions disptachées.

• Autorise le développeur à personnaliser les options de rendu de la vue.

• Donne la possibilité de rendre automatiquement un script de vue.

• Donne accès aux paramètres configurant le chemin de base (base path) et le chemin des scripts (script path), de la vue.

Note: Su vous utilsez _forward(), redirect, ou render manuellement, le rendu automatique sera annulé car ViewRenderer saura que vous prennez la main.

Note: Le ViewRenderer est activé par défaut dans le contrôleur frontal. Pour le désactiver, utilisez le paramètre noViewRenderer ($front->setParam('noViewRenderer', true)) ou retirez l'objet du gestionnaire d'aides (helper broker) (Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer')).
Si vous voulez modifier un paramètre du ViewRenderer avant le dispatching du contrôleur frontal, il existe deux moyens :

• Instanciez et enregistrez votre propre objet ViewRenderer et passez le au gestionnaire d'aides :

  <?php
  $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
  $viewRenderer->setView($view)
               ->setViewSuffix('php');
  Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);?>
                      

• Initialisez et/ou récupérez l'objet ViewRenderer via le gestionnaire d'aides :

  <?php
  $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
  $viewRenderer->setView($view)
               ->setViewSuffix('php');?>
                      

L'usage le plus banal consiste à instancier et passer l'objet ViewRenderer au gestionnaire d'aides. La manière la plus simple est d'utiliser la méthode statique getStaticHelper() du gestionnaire, qui s'occupe de tout ceci en une passe :

<?php
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');?>
        

La première action demandée instancie ou récupère l'objet de vue. A chaque instatiation de contrôleur, la méthode init() de l'objet ViewRenderer est appelée. Elle va configurer la vue et appeller addScriptPath() avec un chemin relatif au dossier courant. Ceci a pour effet de "namespacer" toutes les aides et les filtres de vue pour le module en cours.

A chaque postDispatch() d'action, render() est appelée.

Voici un exemple :

<?php
// Bar controller , module foo :
class Foo_BarController extends Zend_Controller_Action
{
    // Rend bar/index.phtml par défaut; rien à faire c'est automatique
    public function indexAction()
    {
    }

    // Rend bar/populate.phtml avec une variable 'foo' à la valeur 'bar'.
    // l'objet de vue est définit dans le preDispatch(), il est donc accessible.
    public function populateAction()
    {
        $this->view->foo = 'bar';
    }
}

...

// Dans un des scripts de vue :
$this->foo(); // appelle Foo_View_Helper_Foo::foo()?>

        

Le ViewRenderer définit de même des accesseurs pour configurer la vue qu'il encapsule :

• setView($view) Passage de l'objet de vue. Il devient accessible comme une propriété publique de l'objet : $view.

• setNeverRender($flag = true) peut être utilisée pour désactiver le rendu automatique de la vue dans tous les contrôleurs. postDispatch() est alors court-circuitée. getNeverRender() retourne ce paramètre.

• setNoRender($flag = true) peut être utilisée pour désactiver le rendu automatique de la vue dans le contrôleur actuel. postDispatch() est alors court-circuitée, mais preDispatch() réactive le paramètre pour l'action suivante. getNoRender() retourne cette option.

• setNoController($flag = true) est utilisée pour spécifier à render() de ne pas chercher le script de vue dans le sous repertoire après le contrôleur (correspondant à l'action). Par défaut, cette recherche est effectuée. getNoController() retourne ce paramètre.

• setNeverController($flag = true) fonctionne de manière similaire à setNoController(), mais pour tous les contrôleurs.getNeverController() est l'autre accesseur.

• setScriptAction($name) peut être utiliséee pour spécifier le script de vue d'une action à rendre. $name doit être le nom de l'action sans le suffixe (et sans le nom du contrôleur sauf si noController a été activé). Si vous n'utilisez pas cette méthode elle cherchera le script de vue correspondant au nom de l'action en cours (issue de l'objet de requête). getScriptAction() retourne la valeur actuelle de ce paramètre.

• setResponseSegment($name) dit dans quel segment de la réponse rendre le script. Par défaut, la vue est rendue dans le segment par défaut. getResponseSegment() retourne cete valeur.

• initView($path, $prefix, $options) doit être appelée pour configurer la vue : son 'base path', le préfixe de classe pour les filtres et aides, et des options matérialisées par : neverRender, noRender, noController, scriptAction, et responseSegment.

• setRender($action = null, $name = null, $noController = false) vous permet de spécifier les paramètres scriptAction, responseSegment, et noController en une fois. direct() est un alias qui permet un appel rapide depuis le contrôleur :

  // Rend 'foo' au lieu du script correspondant à l'action courante
  $this->_helper->viewRenderer('foo');
  
  // rend form.phtml dans le segment 'html' de la réponse sans utiliser le 
  // sous repertoire contrôleur pour chercher le script de vue :
  $this->_helper->viewRenderer('form', 'html', true);
  
                  

  Note: setRender() et direct() ne rendent pas un script de vue à proprement parler, mais elles notifient au postDispatch() de le faire.
  

Le constructeur de ViewRenderer accepte aussi un objet de vue et un tableau d'options, de la même manière 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);

        

Il est aussi possible de personnaliser les chemins utilisés pour determiner le base path (chemin de base) de la vue ainsi que le script path (chemin vers les scripts de vue). Des méthodes le permettent, utilisez les options suivantes avec :

• :moduleDir représente le module courant (par convention le dossier parent au dossier contrôleur).

• :module pointe vers le module actuel.

• :controller pointe vers le contrôleur actuel.

• :action représente l'action actuellement traitée.

• :suffix est utilisée pour le suffixe du script de vue. setViewSuffix() permet aussi de le modifier.

Toutes ces options s'utilisent avec les méthodes ci-après :

• setViewBasePathSpec($spec) vous permet de changer le dossier donnant accès aux dossiers de la vue : le base path. Par défaut il s'agit de :moduleDir/views. L'accesseur de récupération est getViewBasePathSpec().

• setViewScriptPathSpec($spec) Une fois dans le base path, le rendu cherche le script de vue dans le script path, que cette méthode permet de définir. La valeur par défaut est :controller/:action.:suffix et l'autre accesseur est getViewScriptPathSpec().

• setViewScriptPathNoControllerSpec($spec) Une fois dans le base path, si noController est activé, le rendu cherche le script de vue dans le chemin que cette méthode permet de définir. La valeur par défaut est :action.:suffix et l'autre accesseur est getViewScriptPathNoControllerSpec().

ViewRenderer utilise un inflecteur : Zend_Filter_Inflector, pour résoudre les options de chemin, en chemins réels. Pour une personnalisation maximale, vous pouvez intérragir avec cet inflécteur à l'aide des méthodes suivantes :

• getInflector() retourne l'inflecteur. Si aucun n'existe, ViewRenderer en crée un avec des options par défaut.

  Par défaut, les règles de l'inflecteurs sont statiques autant pour le suffixe et le repertoire module, que pour la cible. Ceci permet au ViewRenderer de modifier ces valeurs dynamiquement.

• setInflector($inflector, $reference) peut être utilisée pour passer son propre inflecteur à ViewRenderer. Si $reference est à true, alors le suffixe, le repertoire du module et la cible seront affectés en fonction des propriétés de ViewRenderer.

Note: Règles de résolution par défaut
Le ViewRenderer utilise certaines règles par défaut pour chercher ses scripts de vue, voyez plutôt :

• :module : casseMélangée et motsCamelCase qui deviennent des mots séparés par des tirets, et en minuscule. "FooBarBaz" devient "foo-bar-baz".

  En interne, l'inflecteur utilise les filtres Zend_Filter_Word_CamelCaseToDash et Zend_Filter_StringToLower.

• :controller : casseMélangée et motsCamelCase qui deviennent des mots séparés par des tiret; les underscores eux, se transforment en séparateur de dossier et tout est passé en minuscules. "FooBar" devient "foo-bar"; "FooBar_Admin" devient "foo-bar/admin".

  En interne, l'inflecteur utilise les filtres Zend_Filter_Word_CamelCaseToDash, Zend_Filter_Word_UnderscoreToSeparator, et Zend_Filter_StringToLower.

• :action : casseMélangée et motsCamelCase qui se transforment en mots séparés par des tirets, minuscules. Les caractères non alphanumeriques deviennent des tirets. "fooBar" devient "foo-bar"; "foo-barBaz" devient "foo-bar-baz".

  Pour ceci, l'inflecteur interne utilise les filtres Zend_Filter_Word_CamelCaseToDash, Zend_Filter_PregReplace, et Zend_Filter_StringToLower.

Enfin, l'API ViewRenderer vous propose aussi des méthodes pour determiner les scripts de vue, et rendre la vue. Celles-ci se décomposent en :

• renderScript($script, $name) va vous permettre de spécifier pleinement le script de vue à rendre, et éventuellement un nom de segment de réponse dans lequel rendre. ViewRenderer s'attend à un paramètre $script représentant un chemin complet vers un script de vue, tel que la méthode de la vue render() l'attend.

  Note: Une fois rendue, la vue utilise noRender pour éviter un double rendu automatisé.
  

  Note: Par défaut, Zend_Controller_Action::renderScript() est un proxy vers la méthode renderScript() de ViewRenderer.
  

• getViewScript($action, $vars) récupère le chemin du script de vue en se basant sur les paramètres $action et $vars. $vars peut contenir 'moduleDir', 'module', 'controller', 'action', et 'suffix'), sinon les valeurs de la requête actuelle seront utilisées.

  getViewScript() utilisera viewScriptPathSpec ou viewScriptPathNoControllerSpec selon le paramètre noController.

  L'inflecteur sera utilisé, par défaut un contrôleur 'foo.bar' et une action 'baz:bat' amèneront à un script de vue 'foo-bar/baz-bat.phtml'.

  Note: Par défaut Zend_Controller_Action::getViewScript() est un proxy vers la méthode getViewScript() de ViewRenderer.
  

• render($action, $name, $noController) a beaucoup de responsabilités : d'abord, elle vérifie si $name ou $noController lui ont été passés, si c'est le cas, elle configure correctement les paramètres responseSegment et noController dans le ViewRenderer. Elle passe ensuite $action, si spécifié, à getViewScript(). Enfin, elle passe le script de vue calculé à renderScript().

  Note: Attention aux effets secondaires avec render() : les valeurs segment de réponse, et noController vont persister dans l'objet ViewRenderer. De plus, noRender() va être appelée.
  

  Note: Par défaut, Zend_Controller_Action::render() est un proxy vers render() de ViewRenderer.
  

• renderBySpec($action, $vars, $name) vous fournit le moyen de passer des paramètres de spécification pour le dossier de script de vue. Cette méthode passe $action et $vars à getScriptPath(), pour en déduire un chemin qu'elle envoie alors avec $name à renderScript().

<?php
// Dans le fichier de démarrage :
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');

...


// 'foo' module, contrôleur 'bar' :
class Foo_BarController extends Zend_Controller_Action
{
    // Rend bar/index.phtml par défaut, rien à faire
    public function indexAction()
    {
    }

    // Rend bar/populate.phtml avec la variable 'foo' à la valeur 'bar'.
    // L'objet de vue est rendu disponible en preDispatch().
    public function populateAction()
    {
        $this->view->foo = 'bar';
    }

    // Ne rend rien, car on demande un nouveau jeton de dispatching
    public function bazAction()
    {
        $this->_forward('index');
    }

    // Ne rend rien, une redirection est demandée
    public function batAction()
    {
        $this->_redirect('/index');
    }
}?>
            

Note: Conventions de noms : délimiteurs de mots dans les noms de contrôleur et d'action
Si les noms de votre contrôleur ou de votre action sont composés de plusieurs mots, le dispatcheur s'attend à ce qu'ils soient séparés par des caractères bien définis, dans l'URL. Le ViewRenderer les transforme alors en '/' pour les chemins, ou tirets '-' pour les mots. Ainsi, un appel à /foo.bar/baz.bat dispatchera FooBarController::bazBatAction() dans FooBarController.php, et ceci rendra foo-bar/baz-bat.phtml. Un appel à /bar_baz/baz-bat dispatchera vers Bar_BazController::bazBatAction() dans Bar/BazController.php (notez la séparation du chemin), et rend bar/baz/baz-bat.phtml.
Notez dans le second exemple, le module est celui par défaut, mais comme un séparateur de chemin (underscore '_') est donné, alors le contrôleur dispatché devient Bar_BazController, dans Bar/BazController.php.

<?php
// Baz controller class, bar module :
class Bar_BazController extends Zend_Controller_Action
{
    public function fooAction()
    {
        // Ne rend pas automatiquement cette action
        $this->_helper->viewRenderer->setNoRender();
    }
}

// Bat controller class, bar module :
class Bar_BatController extends Zend_Controller_Action
{
    public function preDispatch()
    {
        // Ne rend plus aucune action de ce contrôleur
        $this->_helper->viewRenderer->setNoRender();
    }
}?>
            

Note: Utiliser setNeverRender()), pour désactiver totalement le rendu automatique de vue vous fera perdre un des avantages majeur de ViewRenderer.

<?php
// Bar controller class, foo module :
class Foo_BarController extends Zend_Controller_Action
{
    public function addAction()
    {
        // Rend 'bar/form.phtml' plutôt que 'bar/add.phtml'
        $this->_helper->viewRenderer('form');
    }

    public function editAction()
    {
        // Rend 'bar/form.phtml' au lieu de 'bar/edit.phtml'
        $this->_helper->viewRenderer->setScriptAction('form');
    }

    public function processAction()
    {
        // un peu de validation...
        if (!$valid) {
            // Rend 'bar/form.phtml' à la place de 'bar/process.phtml'
            $this->_helper->viewRenderer->setRender('form');
            return;
        }

        // continue le processus...
    }

}?>
            

<?php
// Bar controller class, foo module :
class Foo_BarController extends Zend_Controller_Action
{
    public function preDispatch()
    {
        // change l'encodage de la vue
        $this->view->setEncoding('UTF-8');
    }

    public function bazAction()
    {
        // Récupère l'objet de vue, et lui passe la fonction d'echappement 'htmlspecialchars'
        $view = $this->_helper->viewRenderer->view;
        $view->setEscape('htmlspecialchars');
    }
}?>