Der FlashMessenger Helfer erlaubt es Nachrichten zu übergeben die ein Benutzer bei der nächsten Anfrage sehen können soll. Um das durchführen zu können, berwendet FlashMessenger den Zend_Session_Namespace um Nachrichten für die Zukunft oder den nächsten Empfang einer Anfrage zu speichern. Es ist generell eine gute Idee, das wenn man plant Zend_Session oder Zend_Session_Namespace zu verwenden, diese mit Zend_Session::start() in der Bootstrap Datei zu initialisieren. (Siehe die Zend_Session Dokumentation für weitere Details über die Verwendung)

Das Anwendungsbeispiel von unten zeigt die Verwendung einer Flash Nachricht und Ihre Grundlagen. Wenn die Aktion /some/my aufgerufen wird, fügt Sie die Flash Nachricht "Eintrag gespeichert!" hinzu. Eine weitere Anfrage zu der Aktion /some/my-next-request empfängt Sie (und löscht Sie auch).

<?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()
    {
        /**
         * default method of getting Zend_Controller_Action_Helper_FlashMessenger
         * instance on-demand
         */
        $this->_flashMessenger->addMessage('Eintrag gespeichert!');
    }

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

Der Redirector Helfer erlaubt die Verwendung eines Redirector Objektes um die Notwendigkeiten der Anwendung für das Umleiten zu einer neuen URL zu erfüllen. Er bietet vielfache Vorteile gegenüber der _redirect() Methode. Er ist zum Beispiel fähig seitenweises Verhalten im Redirector Objekt vorzudefinieren oder bietet ein eingebautes goto($action, $controller, $module, $params) Interface ähnlich dem von Zend_Controller_Action::_forward().

Der Redirector hat eine Anzahl von Methoden die verwendet werden können um das Verhalten beim Umleiten zu beeinflussen:

• setCode() kann verwendet werden um den HTTP Antwort Code zu setzen der wärend des Umleitens verwendet werden soll.

• setExit() kann verwendet werden um ein exit() nach einer Umleitung zu erzwingen. Standardmäßig ist dieser aktiviert.

• setGoto() kann verwendet werden um eine Standard URL zu setzen die verwendet wird wenn keine an goto() übergeben wird. Verwendet die API von Zend_Controller_Action::_forward(): setgoto($action, $controller = null, $module = null, array $params = array());

• setGotoRoute() kann verwendet werden um eine URL basierend auf einer registrierten Route zu setzen. Übergeben in einem Array von Schlüssel/Werte Paaren und einem Routernamen, wird die URL anhand des Routertyps und der Definition zusammengebaut.

• setGotoUrl() kann verwendet werden um eine Standard URL zu setzen die verwendet wird wenn keine an gotoUrl() übergeben wird. Akzeptiert einen einzelnen URL String.

• setPrependBase() kann verwendet werden um die BasisURL des Anfrage Objektes einer mit setGotoUrl(), gotoUrl() oder gotoUrlAndExit() definierten URL, voranzustellen.

• setUseAbsoluteUri() kann verwendet werden um den Redirector dazu zu zwingen absolute URIs zu verwenden wenn umgeleitet wird. Wenn diese Option gesetzt ist, verwendet Sie den Wert von $_SERVER['HTTP_HOST'], $_SERVER['SERVER_PORT'], und $_SERVER['HTTPS'] um eine komplete URI zur, durch eine der Umleitungsmethoden, spezifizierten URL zu erstellen. Diese Option ist standardmäßig ausgeschaltet, kann aber in späteren Releases standardmäßig eingeschaltet sein.

Zusätzlich gibt es eine Reihe von Methoden im Redirector für die Bearbeitung der aktuellen Umleitungen:

• goto() verwendet setGoto() (_forward()-ähnlcihe API) um eine URL zu erstellen und eine Umleitung durchzuführen.

• gotoRoute() verwendet setGotoRoute() (route-assembly) um eine URL zu erstellen und eine Umleitung durchzuführen.

• gotoUrl() verwendet setGotoUrl() (URL string) um eine URL zu erstellen und eine Umleitung durchzuführen.

Letztendlich kann die aktuelle Umleitungs URL jederzeit festgestellt werden durch Verwendung von getRedirectUrl().

Der ViewRenderer Helfer wurde designt um die folgenden Ziele erfüllen:

• Entfernen der Notwendigkeit View Objekte innerhalb der Kontroller zu instanzieren; View Objekte werden automatisch mit dem Kontroller registriert.

• Automatisch View Skript, Helfer und Filter Pfade setzen basierend auf dem aktuellen Modul, und den aktuellen Modulnamen automatisch als Klassenprefix für Helfer und Filterklassen assoziieren.

• Ein global vorhandenes View Objekt für alle bearbeitenden Kontroller und Aktionen erstellen.

• Dem Entwickler erlauben das Standard View Rendering Optionen für alle Kontroller gesetzt werden.

• Die Fähigkeit hinzufügen das ein View Skript ohne Intervention automatisch gerendert wird.

• Dem Entwickler erlauben seine eigenen Spezifikationen, für den View Basisnamen und für View Skriptpfade, zu erstellen.

Hinweis: Wenn man ein _forward(), eine Umleitung, oder ein render manuell durchführt, wird kein automatisches rendern erfolgen, da man beim Ausführen von jeder dieser Aktionen dem ViewRenderer mitteilt das man seine eigene Ausgabe durchführen will.

Hinweis: Der ViewRenderer ist standardmäßig aktiviert. Man kann Ihn über den Parameter noViewRenderer des Frontkontrollers deaktivieren ($front->setParam('noViewRenderer', true)) oder den Helfer vom Helfer Broker Stack entfernen (Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer')).
Wenn man Einstellungen vom ViewRenderer vor der Ausführung des Front Kontrollers ändern will, kann das auf zwei Wegen getan werden:

• Instanzieren und Registrieren eines eigenen ViewRenderer Objekts und dieses an den Helfer Broker übergeben:

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

• Initialisieren und/oder empfangen eines ViewRenderer Objekts auf Wunsch über den Helfer Broker:

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

In seiner einfachsten Verwendung, kann der ViewRenderer ganz einfach instanziert und an den Aktion Helfer Broker übergeben werden. Der einfachste Weg Ihn auf einmal zu Instanzieren und Registrieren ist es, die Methode getStaticHelper() des Helfer Brokers zu verwenden:

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

Das erste Mal wenn ein Aktion Kontroller instanziert wird, triggert er den ViewRenderer ein View Objekt zu instanzieren. Jedes Mal wen ein Kontroller Instanziert wird, wird die init() Methode des ViewRenderer's aufgerufen, was dazu führt das er die view Eigenschaft des Aktion Kontrollers setzt, und addScriptPath(), mit einem Pfad relativ zum aktuellen Modul, aufruft; das wird mit einem Klassenprefix aufgerufen der nach dem aktuellen Modul benannt ist, was effektiv für alle Helfer und Filterklassen die im Modul definiert werden den Namensraum setzt.

Jedes Mal wenn postDispatch() aufgerufen wird, ruft dieses render() für die aktuelle Aktion auf.

Als Beispiel kann die folgende Klasse angenommen werden:

<?php
// Eine Kontroller Klasse, foo Modul:
class Foo_BarController extends Zend_Controller_Action
{
    // Rendert standardmäßig bar/index.phtml; keine Aktion benötigt
    public function indexAction()
    {
    }

    // Rendert bar/populate.phtml mit der Variable 'foo' gesetzt auf 'bar'.
    // Da View Objekte beim preDispatch() definiert werden, sind diese bereits vorhanden.
    public function populateAction()
    {
        $this->view->foo = 'bar';
    }
}

...

// In einem der View Sktipte:
<?php $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
        

Der ViewRenderer definiert auch eine Anzahl von Zugriffspunkten im das Setzen und Empfangen von View Optionen zu erlauben:

• setView($view) erlaubt das Setzen des View Objektes für den ViewRenderer. Er wird als öffentliche Klasseneigenschaft $view gesetzt.

• setNeverRender($flag = true) kann verwendet werden um das automatische rendern global ein- oder auszuschalten, z.B. für alle Kontroller. Wenn er auf true gesetzt wird, ruft postDispatch() nicht automatisch render() im aktuellen Kontroller auf. getNeverRender() empfängt den aktuellen Wert.

• setNoRender($flag = true) kann verwendet werden um das automatische rendern ein- oder auszuschalten. Wenn er auf true gesetzt wird, wird postDispatch() render() im aktuellen Kontroller nicht automatisch aufrufen. Diese Einstellung wird jedesmal zurückgesetzt wenn preDispatch() aufgerufen wird (z.B. muß dieses Flag für jeden Kontroller gesetzt werden für den das automatische rendern nicht automatisch stattfinden soll). getNoRender() empfängt den aktuellen Wert.

• setNoController($flag = true) kann verwendet werden um render() zu sagen das für Aktion Skripts nicht in einem Unterverzeichnis gesucht werden soll das nach dem Kontroller benannt ist (was das Standardverhalten ist). getNoController() empfängt den aktuellen Wert.

• setNeverController($flag = true) ist analog zu setNoController(), arbeitet aber auf einem globalen Leven -- z.B. wird es nicht für jede ausgeführte Aktion resetiert. getNeverController() empfängt den aktuellen Wert.

• setScriptAction($name) kann verwendet werden um das Aktion Skript zu spezifizieren das gerendert werden soll. $name sollte der Name des Skripts sein, ohne den Datei Suffix (und ohne das Kontroller Unterverzeichnis, ausser wenn noController eingeschaltet wurde). Wenn nicht spezifiziert, wird nach einem View Skript gesucht das nach der Aktion in Anfrage Objekt benannt ist. getScriptAction() empfängt den aktuellen Wert.

• setResponseSegment($name) kann verwendet werden um zu spezifizieren in welches Segment das nach einem Antwort Objekt benannt ist, gerendert werden soll. Wenn nicht spezifiziert, wird in das Standard Segment gerendert. getResponseSegment() empfängt den aktuellen Wert.

• initView($path, $prefix, $options kann aufgerufen werden um den Basis View Pfad, den Klassenprefix für Helfer, Filter Skripts und ViewRenderer Optionen zu spezifizieren. Es kann eines der folgenden Flags übergeben werden: neverRender, noRender, noController, scriptAction, und responseSegment.

• setRender($action = null, $name = null, $noController = false) erlaubt es scriptAction, responseSegment, oder noController in einem Schritt zu übergeben. direct() ist ein Alias für diese Methode, und erlaubt es diese Methode einfach vom eigenen Kontroller aus aufzurufen:

  // Rendert 'foo' statt dem aktuellen Aktion Skript
  $this->_helper->viewRenderer('foo');
  
  // Rendert form.phtml zum 'html' Antwort Segment, ohne einen Kontroller aus dem
  // Unterverzeichnis des View Skripts zu verwenden:
  $this->_helper->viewRenderer('form', 'html', true);
  
                  

  Hinweis: setRender() und direct() don't actually render the view script, but instead set hints that postDispatch() and render() will use to render the view.
  

The constructor allows you to optionally pass the view object and ViewRenderer options; it accepts the same flags as initView():

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

        

Es gibt einige zusätzliche Methoden für das individualisieren von Pfadspezifikationen die für das Herausfinden des Basis View Pfades verwendet werden der dem View Objekt hinzugefügt wird, und den View Skript Pfad der verwendet wird wenn das View Skript zu dem gerendert werden soll automatisch herausgefunden wird. Diese Methoden nehmen alle ein oder mehrere der folgenden Platzhalter:

• :moduleDir zeigt auf das aktuelle Modul Basisverzeichnis (von der Konvention her das Elternverzeicnis des Kontroller Verzeichnisses des Moduls).

• :module zeigt auf den aktuellen Modulnamen.

• :controller zeigt auf den aktuellen Kontrollernamen.

• :action zeigt auf den aktuellen Aktionsnamen.

• :suffix zeigt auf das aktuelle Suffix des View Skripts (welcher über setViewSuffix() gesetzt werden kann).

Die Methoden für das kontrollieren der Pfad Spezifikationen sind:

• setViewBasePathSpec($spec) erlaubt die Änderung der Pfad Spezifikation die verwendet wird um den Basispfad herauszufinden zu dem das View Objekt hinzugefügt werden soll. Die aktuelle Spezifikation kann jederzeit durch Verwenden von getViewBasePathSpec() erhalten werden.

• setViewScriptPathSpec($spec) erlaubt die Änderung der Pfad Spezifikation die verwendet wird um den Pfad zu einem individuellen View Skript herauszufinden (ohne den Basis View Skript Pfad). Die Standard Spezifikation ist :controller/:action.:suffix. Die aktuelle Spezifikation kann jederzeit durch Verwenden von getViewScriptPathSpec() erhalten werden.

• setViewScriptPathNoControllerSpec($spec) erlaubt die Änderung der Pfad Spezifkiation die verwendet wird um den Pfad zu einem individuellen View Skript herauszufinden wenn noController aktiv ist (ohne den Basis View Skript Pfad). Die Standard Spezifikation ist :action.:suffix. Die aktuelle Spezikifation kann jederzeit durch Verwenden von getViewScriptPathNoControllerSpec() erhalten werden.

Die letzten Teile in der ViewRenderer API sind die Methoden für das aktuelle herausfinden von View Skript Pfaden und Rendern von Views. Diese beinhalten:

• renderScript($script, $name) erlaubt es ein Skript mit einem selbst spezifizierten Pfad zu rendern, optional zu einem benannten Pfad Segment. Wenn diese Methode verwendet wird, ermittelt der ViewRenderer nicht automatisch den Skriptnamen sondern übergibt das $script Argument direkt der render() Methode des View Objekts.

  Hinweis: Sobald die View zum Antwort Objekt gerendert wurde, setzt diese noRender um irrtümliches mehrfaches rendern zum selben View Skript zu verhindern.
  

  Hinweis: Standardmäßig handelt Zend_Controller_Action::renderScript() in Vertretung zur renderScript() Methode des ViewRenderer's.
  

• getViewScript($action, $vars) erstellt den Pfad zu einem View Skript das auf einer Aktion basiert die übergeben wird, und/oder allen Variablen die in $vars übergeben werden. Schlüssel für dieses Array können jede der Pfad Spezifikations Schhüssel enthalten ('moduleDir', 'module', 'controller', 'action', und 'suffix'). Jede übergebene Variable wird verwendet; andernfalls werden Werte die auf der aktuellen Anfrage basieren angewendet.

  getViewScript() verwendet entweder viewScriptPathSpec oder viewScriptPathNoControllerSpec basierend auf den Einstellungen des noController Flags.

  Wortbegrenzer die in Modul-, Kontroller- oder Aktionsnamen vorkommen werden mit Bindestrichen ('-') ersetzt. Deshalb resultiert, wenn der Kontrollername 'foo.bar' und die Aktion 'baz:bat' ist, die Verwendung der standard Pfad Spezifikation einen View Skript Pfad von 'foo-bar/baz-bat.phtml'.

  Hinweis: Standardmäßig handelt Zend_Controller_Action::getViewScript() in Vertretung zur getViewScript() Methode des ViewRenderer's.
  

• render($action, $name, $noController) prüft zuerst ob entweder $name oder $noController übergeben wurde, und wenn dem so ist, wird das betreffende Flag (respektive responseSegment und noController) im ViewRenderer gesetzt. Dann übergibt er das $action Argument, wenn vorhanden, an getViewScript(). Am Ende wird der berechnete View Skript Pfad an renderScript() übergeben.

  Hinweis: Achtung vor den Nebeneffekten bei der Verwendung von render(): Die Werte die für den Anwort Segment Namen und für das noController Flag übergeben werden sind im Objekt dauerhaft. Zusätzlich wird noRender gesetzt nachdem das rendern fertig ist.
  

  Hinweis: Standardmäßig handelt Zend_Controller_Action::render() in Vertretung zur render() Methode des ViewRenderer's.
  

• renderBySpec($action, $vars, $name) erlaubt es Pfad Spezifikations Variablen zu übergeben um den View Skript Pfad zu ermitteln der erstellt werden soll. Es übergibt $action und $vars an getScriptPath() und übergibt anschließend den resultierenden Skript Pfad und $name an renderScript().

<?php
// In der Bootstrap Datei:
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');

...

<?php
// 'foo' Modul, 'bar' Kontroller:
class Foo_BarController extends Zend_Controller_Action
{
    // Rendert standardmäßig bar/index.phtml; keine Aktion benötigt
    public function indexAction()
    {
    }

    // Rendert bar/populate.phtml wobei die Variable 'foo' auf 'bar' gesetzt wird.
    // Da das View Objekt beim preDispatch() definiert wird, ist es bereits vorhanden.
    public function populateAction()
    {
        $this->view->foo = 'bar';
    }

    // Rendert nichts da zu einer anderen Aktion weitergeleitet wird; die neue Akion
    // wird jegliches rendern durchführen
    public function bazAction()
    {
        $this->_forward('index');
    }

    // Rendert nichts da zu einer anderen Lokation weitergeleitet wird
    public function batAction()
    {
        $this->_redirect('/index');
    }
}
            

Hinweis: Benamungs Konventionen: Wort Begrenzer in Kontroller- und Aktionnamen
Wenn der Kontroller- oder Aktionsname aus mehreren Wörtern aufgebaut ist, müssen diese, da der Dispatcher das benötigt, seperiert sein durch die URL nach spezifischem Pfad und Wort Begrenzer Zeichen. Der ViewRenderer ersetzt jeden Pfad Begrenzer den er im Kontrollernamen findet mit einem aktuellen Pfad Begrenzer ('/'), und jeden Wort Begrenzer der gefunden wird mit einem Bindestrich ('-') wenn Pfade erstellt werden. Deshalb würde ein Aufruf der Aktion /foo.bar/baz.bat zu FooBarController::bazBatAction() in FooBarControll.php weiterleiten was wiederum foo-bar/baz-bat.phtml rendern würde; ein Aufruf der Aktion /bar_baz/baz-bat für dazu das Bar_BazController::bazBatAction() in Bar/BazController.php dispatched wird (betrachte die Seperation des Pfades) und bar/baz/baz-bat.phtml gerendert wird.
Es ist zu beachten das im zweiten Beispiel, das Modul noch immer das Standardmodul ist, aber das der Kontroller, wegen der Existenz eines Pfad Seperators, den Namen Bar_BazController in Bar/BazController.php empfängt. Der ViewRenderer emuliert die Kontroller Verzeichnis Hierarchie.

<?php
// Baz Kontroller Klasse, bar Modul:
class Bar_BazController extends Zend_Controller_Action
{
    public function fooAction()
    {
        // Diese Sektion nicht automatisch Rendern
        $this->_helper->viewRenderer->setNoRender();
    }
}

// Bat Kontroller Klasse, Bar Modul:
class Bar_BatController extends Zend_Controller_Action
{
    public function preDispatch()
    {
        // Die Aktionen dieses Kontroller nie automatisch Rendern
        $this->_helper->viewRenderer->setNoRender();
    }
}
            

Hinweis: In den meisten Fällen, macht es keinen Sinn das automatische Rendern global auszuschalten (ala setNeverRender()), da das einzige das man dann vom ViewRenderer erhält das automatische Setup des View Objekts ist.

<?php
// Bar Kontroller Klasse, foo Modul:
class Foo_BarController extends Zend_Controller_Action
{
    public function addAction()
    {
        // Rendert 'bar/form.phtml' statt 'bar/add.phtml'
        $this->_helper->viewRenderer('form');
    }

    public function editAction()
    {
        // Rendert 'bar/form.phtml' statt 'bar/edit.phtml'
        $this->_helper->viewRenderer->setScriptAction('form');
    }

    public function processAction()
    {
        // einige Prüfungen durchführen...
        if (!$valid) {
            // Rendert 'bar/form.phtml' statt 'bar/process.phtml'
            $this->_helper->viewRenderer->setRender('form');
            return;
        }

        // andernfalls die Bearbeitung weiter durchführen...
    }

}
            

<?php
// Bar Kontroller Klasse, foo Modul:
class Foo_BarController extends Zend_Controller_Action
{
    public function preDispatch()
    {
        // Die Kodierung der View ändern
        $this->view->setEncoding('UTF-8');
    }

    public function bazAction()
    {
        // Das View Objekt erhalten, und den Kommentar Callback auf 'htmlspecialchars' setzen
        $view = $this->_helper->viewRenderer->view;
        $view->setEscape('htmlspecialchars');
    }
}