Action Helfer
Einführung
Aktion Helfer erlauben Entwicklern Runtime und/oder On-Demand Funktionalität in jeden
Aktion Controller zu inizieren der Zend_Controller_Action
erweitert. Aktion Controller versuchen den Notwendigkeit zu minimieren, den abstrakten
Aktion Controller zu erweitern um damit normale Aktion Controller Funktionen inizieren.
Es gibt eine Menge an Wegen um Aktion Helfer zu verwenden. Aktion Helfer verwenden ein
Broker System, ähnlich den Typen von Brokern in Zend_View_Helper, und denen von Zend_Controller_Plugin. Aktion Helfer
Zend_View_Helper) können bei Bedarf geladen und aufgerufen
werden, oder Sie können wärend der Anfragezeit (Bootstrap) instanziert werden oder
wären der Erstellungszeit des Aktion Controllers ( init()). Um
Sie näher zu verstehen, betrachten wir Ihre Verwendung in der folgenden Sektion.
Helfer Initialisierung
Ein Helfer kann auf vielen verschiedenen Wegen initialisiert werden, basierend auf den
eigenen Bedürfnissen und den Funktionalitäten dieses Helfers.
Ein Helfer Broker wir das der $_helper Teilnehmer von
Zend_Controller_Action gespeichert; der Broker kann verwendet
werden um Helfer zu empfangen oder aufzurufen. Einige Methoden das zu tun sind:
-
Explizit getHelper() verwenden. Ihm einfach einen
Namen übergeben und ein Helfer Objekt wird zurückgegeben:
$flashMessenger = $this->_helper->getHelper('FlashMessenger');
$flashMessenger->addMessage('Wir haben in der letzten Anfrage etwas getan');
-
Verwenden der __get() Funktionalität des Helfer
Brokers und Empfangen des Helfers wie wenn er eine Teilnehmer Eigenschaft des
Brokers wäre:
$flashMessenger = $this->_helper->FlashMessenger;
$flashMessenger->addMessage('Wir haben in der letzten Anfrage etwas getan');
-
Letztendlich implmentieren die meisten Aktion Helfer die
direct() Methode welche eine spezielle,
Standardmethode im Helfer aufruft. In Beispiel des
FlashMessenger's, wird
addMessage() aufgerufen:
$this->_helper->FlashMessenger('Wir haben in der letzten Anfrage etwas getan');
Note:
Alle oben angeführten Beispiel sind funktionell gleichwertig.
Man kann Helfer auch explizit instanzieren. Das kann gewollt sein wenn der Helfer
ausserhalb eines Aktion Controllers verwendet werden soll, oder wenn ein Helfer an einen
Helfer Broker übergeben wird um Ihn durch irgendeine Aktion zu verwenden. Instanziert
wird er wie jede andere PHP Klasse.
Der Helfer Broker
Zend_Controller_Action_HelperBroker behandelt die Details der
Registrierung von Helfer Objekten und Helfer Pfaden, sowie dem Empfangen von Helfern bei
Befarf.
Um einen Helfer im Browser zu registrieren, kann addHelper()
verwendet werden:
Zend_Controller_Action_HelperBroker::addHelper($helper);
Natürlich ist das Instanzieren und übergeben von Helfern an den Broker etwas Zeit- und
Ressourcen intensiv, weswegen twei Methoden existieren um die Dinge etwas zu
automatisieren: addPrefix() und
addPath().
-
addPrefix() nimmt einen Klassenpräfix und verwendet
Ihn um einen Pfad zu ermitteln wo Helferklassen definiert wurden. Er nimmt an
das der Präfix den Konventionen der Benamung von Klassen im Zend Framework
folgt.
// Helfer mit vorangestelltem My_Action_Helpers in My/Action/Helpers/ hinzufügen
Zend_Controller_Action_HelperBroker::addPrefix('My_Action_Helpers');
-
addPath() nimmt ein Verzeichnis als erstes Argument
und einen Klassenprefix als zweites Argument (Standardwert ist
'Zend_Controller_Action_Helper'). Das erlaubt es die
eigenen Klassenpräfixes mit speziellen Verzeichnissen zu verbinden.
// Helfer mit vorangestelltem Helper in Plugins/Helpers/ hinzufügen
Zend_Controller_Action_HelperBroker::addPath('./Plugins/Helpers',
'Helper');
Da diese Methoden statisch sind, können Sie zu jeder Zeit in der Controllerkette
aufgerufen werden um Helfer dynamisch hinzuzufügen wenn es notwendig wird.
Intern verwendet der Helfer Broker eine
Instanz des PluginLoader's um die Pfade zu verwalten. Man erhlt den PluginLoader
indem die statische Methode getPluginLoader() verwendet, oder
alternativ, eine eigene PluginLoader Instanz einfügt durch Verwenden von
setPluginLoader().
Um zu ermitteln ob ein Helfer im Helfer Broker existiert, kann
hasHelper($name) verwendet werden, wobei
$name der Kurzname des Helfers ist (ohne das Präfix):
// Prüft ob der 'redirector' Helfer im Broker registriert ist:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
echo 'Der Redirector Helfer ist registriert';
}
Es gibt auch zwei statische Methoden für das bekommen von Helfern vom Helferbroker:
getExistingHelper() und
getStaticHelper().
getExistingHelper() empfängt einen Helfer nur dann wenn er
davor durch den Helferbroker ausgerufen wirde oder explizit in Ihm registriert wurde;
wenn nicht wird eine Ausnahme geworfen. getStaticHelper()
macht das selbe wie getExistingHelper(), wird aber versuchen
den Helfer zu initiieren wenn dieser davor noch nicht im Helferstack registriert wurde.
getStaticHelper() ist eine gute Wahl für das empfangen von
Helfern welche man konfigurieren will.
Beide Methoden nehmen ein einzelnes Argument, $name, welches der
Kurzname des Helfers (ohne den Präfix) ist.
// Prüfe ob der 'redirector' Helfer im Broker registriert ist und holt Ihn:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
$redirector =
Zend_Controller_Action_HelperBroker::getExistingHelper('redirector');
}
// Oder, Ihn einfach empfangen, ohne darüber nachzudenken ob er bereits
// registriert wurde oder nicht:
$redirector =
Zend_Controller_Action_HelperBroker::getStaticHelper('redirector');
}
Schlußendlich, um einen registrierten Helfer vom Broker zu entfernen, kann
removeHelper($name) verwendet werden, wobei
$name der Kurzname des Helfers ist (ohne den Prefix):
// Wenn vorhanden, entferne den 'redirector' Helfer vom Broker:
if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
Zend_Controller_Action_HelperBroker::removeHelper('redirector')
}
Eingebaute Aktions Helfer
Zend Framework enthält standardmäßig verschiedene Action Helfer:
AutoComplete für automatisierte Antworten für
AJAX Autovervollständigung; ContextSwitch und
AjaxContext für alternative Antwort Formate eigener Aktionen;
einen FlashMessenger für die Behandlung von Kurznachrichten;
Json für das verschlüsseln und senden von JSON
Antworten; einen Redirector, um verschiedene Implementationen, für
das Umleiten zu internen und externen Seiten, für die Anwendung bereitzustellen und
einen ViewRenderer um den Prozess des Setzens eines View Objekts
im Controller und dem Rendern von Views zu automatisieren.
ActionStack
Der ActionStack Helfer erlaubt das Verschieben von Anfragen zum ActionStack Front
Controller Plugin, welches effektiv hilft um eine Queue von Aktionen zu erstellen die wärend
der Anfrage ausgeführt wird. Der Helfer erlaubt das hinzufügen von Aktionen entweder durch
Spezifikation von neuen Anfrage Objekten oder Aktion - Controller - Modul Sets.
Note: Der Aufruf des ActionStack Helpers inizialisiert das ActionStack Plugin
Der Aufruf des ActionStack Helpers registriert das
ActionStack Plugin implizit -- was bedeutet dass das
ActionStack Plugin nicht explizit registriert werden muß um dessen
Funktionalität zu verwenden.
Example #1
Eine Aufgabe hinzufügen indem Aktion, Controller und Modulnamen verwendet werden
Oft ist es am einfachsten, einfach die Aktion, den Controller und das Modul (und
optionale Anfrage Parameter) zu spezifizieren, wie wenn
Zend_Controller_Action::_forward() aufgerufen werden würde:
class FooController extends Zend_Controller_Action
{
public function barAction()
{
// Dem Stack zwei Aktionen hinzufügen
// Und /foo/baz/bar/baz aufrufen
// (FooController::bazAction() mit der Anfrage var bar == baz)
$this->_helper->actionStack('baz',
'foo',
'default',
// Aufruf für /bar/bat hinzufügen
// (BarController::batAction())
$this->_helper->actionStack('bat', 'bar');
}
}
Example #2 Eine Aufgabe hinzufügen durch Verwendung eines Anfrage Objektes
Machmal macht die OOP Natur eines Anfrage Objektes mehr Sinn; solch
ein Objekt kann dem ActionStack Helfer genauso übergeben werden.
class FooController extends Zend_Controller_Action
{
public function barAction()
{
// Dem Stack zwei Aktionen hinzufügen
// Aufruf zu /foo/baz/bar/baz hinzufügen
// (FooController::bazAction() mit der Anfrage var bar == baz)
$request = clone $this->getRequest();
// Controller oder Modul nicht setzen, verwende aktuelle Werte
$request->setActionName('baz')
-> setParams(array('bar' => 'baz'));
$this->_helper->actionStack($request);
// Aufruf zu /bar/bat hinzufügen
// (BarController::batAction())
$request = clone $this->getRequest();
// Modul nicht setzen, verwende aktuelle Werte
$request->setActionName('bat')
->setControllerName('bar');
$this->_helper->actionStack($request);
}
}
AutoComplete
Viele AJAX Javascript Bibliotheken bieten Funktionalitäten an für eine
automatische Vervollständigung wobei eine Auswahlliste von potentiell passenden Ergebnissen
angezeigt wird während der Benutzer tippt. Der AutoComplete Helfer
zielt darauf ab einfach akzeptierbare Ergebnisse zu solchen Methoden zurückzugeben.
Da nicht alle JS Bibliotheken automatische Vervollständigung auf die gleiche Art
implementieren bietet der AutoComplete Helfer einige grundsätzliche
abstrakte Funktionalitäten zu vielen Bibliotheken und konkrete Implementierungen für
individuelle Bibliotheken. Zurückgegebene Typen sind generell entweder
JSON Arrays von Strings, JSON Arrays von Arrays (mit
jedem Mitgliedsarray das ein assoziatives Array von Metadaten ist, das verwendet wird um
die Auswahlliste zu erstellen), oder HTML.
Die grundsätzliche Verwendung ist für jede Implementierung die selbe:
class FooController extends Zend_Controller_Action
{
public function barAction()
{
// etwas Logik durchführen...
// Verschlüsseln und Antwort senden;
$this->_helper->autoCompleteDojo($data);
// oder explizit:
$response = $this->_helper->autoCompleteDojo
->sendAutoCompletion($data);
// oder einfach die Antwort der automatischen
// Vervollständigung vorbereiten;
$response = $this->_helper->autoCompleteDojo
->prepareAutoCompletion($data);
}
}
Standardmäßig mach die automatische Vervollständigung folgendes:
Layouts und ViewRenderer ausschalten.
Die richtigen Antwort Header zu setzen.
-
Antwort Body mit verschlüsselten oder formatierten automatisch vervollständigten
Daten setzen.
Antwort senden.
Mögliche Methoden des Helfers beinhalten:
-
disableLayouts() kann verwendet werden um Layouts und den
ViewRenderer auszuschalten. Typischerweise wird das innerhalb von
prepareAutoCompletion() aufgerufen.
-
encodeJson($data, $keepLayouts = false) verschlüsselt
Daten zu JSON, und aktiviert oder deaktiviert Layouts optional.
Typischerweise wird das innerhalb von
prepareAutoCompletion() aufgerufen.
-
prepareAutoCompletion($data, $keepLayouts = false) wird
verwendet um Daten im Antwortformat vorzubereiten wenn das für die konkrete
Implementation notwendig ist, wobei Layouts optional aktiviert oder deaktiviert
werden können. Der Rückgabewert variiert basierend auf der Implementierung.
-
sendAutoCompletion($data, $keepLayouts = false) wird
verwendet um Daten im Antwortformat zu senden was für die konkrete Implementierung
notendig ist. Sie ruft prepareAutoCompletion() und sendet
dann die Antwort.
-
direct($data, $sendNow = true, $keepLayouts = false) wird
verwendet wenn der Helfer als Methode des Helfer Brokers aufgerufen wird. Das
$sendNow Flag wird verwendet um festzustellen ob
sendAutoCompletion() oder
prepareAutoCompletion() aufgerufen werden muß.
Aktuell unterstützt AutoComplete die folgenden Dojo und Scriptaculous
AJAX Bibliotheken.
AutoCompletion mit Dojo
Dojo hat per se keinen AutoCompletion Wizard, hat aber zwei Wizards die AutoCompletion
ausführen können: ComboBox und FilteringSelect. In beiden Fällen benötigen Sie einen
Datenspeicher der QueryReadStore implementiert; für mehr Informationen über dieses
Thema siehe die » dojo.data
Dokumentation.
Im Zend Framework kann ein einfaches indiziertes Array an den AutoCompletionDojo Helfer
übergeben werden, und er wird eine JSON Antwort zurückgeben die
passend für die Verwendung in so einem Speicher ist:
// In der Controller Aktion:
$this->_helper->autoCompleteDojo($data);
Example #3 AutoCompletion mit Dojo und der Verwendung von Zend MVC
AutoCompletion mit Dojo, über Zend MVC, benötigt verschiedene
Dinge: Erstellung eines Form Objekts für die Kombobox bei der man AutoCompletion
will, eine Controller Action für das anbieten der AutoCompletion Ergebnisse,
Erstellung eines eigenen QueryReadSote um die AutoCompletion Aktion damit zu
verbinden, und Erstellung des Javascripts das zur Initialisierung der
AutoCompletion auf der Serverseite zu verwenden ist.
Schauen wir uns zuerst das benötigte Javascript an. Dojo bietet ein komplettes
Framework für die Erstellung von OOP Javascript, so wie Zend
Framework für PHP. Teile davon sind die Möglichkeit
Pseudo-Namespaces zu erstellen indem die Verzeichnis Hirarchie verwendet wird. Wir
erstellen ein 'custom' Verzeichnis auf dem gleichen Level wie das Dojo Verzeichnis
das Teil der Distribution von Dojo ist. In diesem Verzeichnis, erstellen wir eine
Javascript Datei, TestNameReadStore.js, mit den folgenden
Inhalten:
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);
}
});
Diese Klasse ist einfach eine Erweiterung von Dojo's eigenem QueryReadStore,
welche selbst eine Abstrakte Klasse ist. Wir definieren einfach eine Methode mit
der angefragt werden soll, und verknüpfen Sie mit dem 'test' Element.
Als nächstes, erstellen wir das Form Element für das wir AutoCompletion wollen:
class TestController extends Zend_Controller_Action
{
protected $_form;
public function getForm()
{
if (null === $this->_form) {
$this->_form = new Zend_Form();
$this->_form->setMethod('get')
->setAction(
$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;
}
}
Hier erstellen wir einfach eine Form mit den 'test' und 'go' Methoden. Die 'test'
Methode fügt verschiedene spezielle, Dojo-spezifische Attribute hinzu: dojoType,
store, autoComplete, und hasDownArrow. Der dojoType wird verwendet um anzuzeigen
das wir eine ComboBox erstellen, und wir Sie zum Datenspeicher von 'testStore'
verbinden wollen (Schlüssel 'store') -- mehr dazu später. Die Spezifizierung von
'autoComplete' mit FALSE sagt Dojo das der erste passende
Eintrag nicht automatisch ausgewählt wird, aber stattdessen eine Liste von
Entsprechnungen angezeigt wird. Letztendlich, erstellt 'hasDownArrow' einen
Abwärtspfeil ähnlich einer Selectbox sodas Wir die Entsprechnungen zeigen und
verstecken können.
Fügen wir eine Methode hinzu um die Form anzuzeigen, sowie einen Endpunkt für die
Bearbeitung der AutoCompletion:
class TestController extends Zend_Controller_Action
{
// ...
/**
* Startseite
*/
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', ''));
foreach ($this->getData() as $datum) {
if (0 === strpos($datum, $match)) {
$matches[] = $datum;
}
}
$this->_helper->autoCompleteDojo($matches);
}
}
in unserer autocompleteAction() machen wir eine Anzahl von
Dingen. Zuerst schauen wir darauf eine Post Anfrage durchzuführen, und das dort ein
'format' Parameter auf den Wert 'ajax' gesetzt ist; das hilft einfach störende
Anfragen zur Aktion zu reduzieren. Als nächstes prüfen wir auf den 'test'
Parameter, und vergleichen Ihn mit unseren Daten. (wir haben absichtlich die
Implementation von getData() hier ausgelassen -- es können
einfach jede Art von Datenquelle sein.) Letztendlich senden wir unsere
Entsprechungen zum AutoCompletion Helfer.
Jetzt da wir alle Teile des Backends haben, sehen wir uns an was wir benötigen um
es in unserem View Skript für die Startseite auszugeben. Zuerst müssen wir unseren
Datenspeicher einstellen, dann unsere Form darstellen, und letztendlich
sicherstellen das die richtigen Dojo Bibliotheken -- inklusive unserer eigenen
Datenspeicher -- geladen werden. Schauen wir uns das View Skript an, das die
Schritte kommentiert:
<?php // Den Datenspeicher einstellen: ?>
<div dojoType="custom.TestNameReadStore" jsId="testStore"
url="<?php echo $this->baseUrl() ?>/unit-test/autocomplete/format/ajax"
requestMethod="get"></div>
<?php // Die Form darstellen: ?>
<?php echo $this-> form ?>
<?php // Das Dojo-betreffende CSS einstellen das im
// HTML Head geladen werden soll: ?>
<?php $this->headStyle()->captureStart() ?>
@import "<?php echo $this->baseUrl()
?>/javascript/dijit/themes/tundra/tundra.css";
@import "<?php echo $this->baseUrl() ?>/javascript/dojo/resources/dojo.css";
<?php $this->headStyle()->captureEnd() ?>
<?php // Javascript einstellen das im HTML Head geladen werden soll,
// inklusive aller benötigten Dojo Bibliotheken: ?>
<?php $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");
<?php $this->headScript()->captureEnd() ?>
Beachte die Aufrufe zu den View Helfern wie headStyle und headScript; das sind
Platzhalter, welche dann in der HTML Head Sektion des Layout
View Skripts dargestellt werden können.
Wir haben jetzt alle Teil um mit Dojo AutoCompletion zu arbeiten.
AutoCompletion mit Scriptaculous
» Scriptaculous
erwartet eine HTML Antwort in einem speziellen Format.
Der Helfer der mit dieser Bibliothek zu verwenden ist 'AutoCompleteScriptaculous'.
Es muß einfach ein Array von Daten angegeben werden, und der Helfer wird eine
HTML Antwort erstellen die mit Ajax.Autocompleter kompatibel ist.
ContextSwitch und AjaxContext
Der ContextSwitch Action Helfer ist vorgesehen für die Erleicherung
bei der Rückgabe von unserschiedlichen Antwortformaten oder Anfragen. Der
AjaxContext Helfer ist eine spezialisierte Version von
ContextSwitch welche die Rückgabe von Antworten zu XmlHttpRequests
erleichtert.
Um einen von Ihnen zu aktivieren, muß der Controller darauf hingewiesen werden welche
Aktion zu welchem Kontext antworten kann. Wenn eine hereinkommende Anfrage einen gültigen
Kontext für eine gegebene Aktion indiziert, dann wird der Helfer:
das Layout ausschalten wenn es eingeschaltet ist.
-
einen alternativen View suffix setzen, was effektiv ein separates View Skript für
den Kontext benötigt.
-
die richtigen Antwort Header für den gewünschten Kontext senden.
-
optional den spezifizierten Callback aufrufen um den Kontext zu definieren und/oder
anschließende Berechnungen durchführen.
Als Beispiel wird der folgende Controller angenommen:
class NewsController extends Zend_Controller_Action
{
/**
* Landeseite; leitet zu listAction() weiter
*/
public function indexAction()
{
$this->_forward('list');
}
/**
* News Items auflisten
*/
public function listAction()
{
}
/**
* Ein News Item anzeigen
*/
public function viewAction()
{
}
}
Angenommen wir wollen das listAction() auch im
XML Format vorhanden ist. Statt der Erstellung einer anderen Aktion,
kann angezeigt werden das eine XML Antwort zurückgegeben wird:
class NewsController extends Zend_Controller_Action
{
public function init()
{
$contextSwitch = $this->_helper->getHelper('contextSwitch');
$contextSwitch->addActionContext('list', 'xml')
->initContext();
}
// ...
}
Was macht das:
-
Setzt den 'Content-Type' Antwort Header auf 'text/xml'.
-
Ändert den View Suffix auf 'xml.phtml' (oder, wenn ein
alternativer View Suffix verwendet wird, 'xml.[dein Suffix]').
Jetzt muß ein neues View Skript erstellt werden,
'news/list.xml.phtml', welches das XML erzeugt und
darstellt.
Um zu ermitteln ob eine Anfrage eine Kontextänderung initiiert, prüft der Helfer auf ein
token im Anfrage Objekt. Standardäßig schaut er auf den 'format' Parameter, durch den das
konfiguriert werden kann. Das bedeutet das, in den meisten Fällen, um eine Kontextänderung
zu triggern, ein 'format' Parameter in der Anfrage hinzugefügt werden kann:
-
über URL Parameter: /news/list/format/xml
(beachte, das Standard Routing Schema erlaubt übliche Schlüssel/Werte Paare nach
der Aktion)
-
über GET Parameter: z.B.,
/news/list?format=xml
ContextSwitch erlaubt es beliebige Kontexte zu spezifizieren,
inklusive welche Kontextänderung stattfinden wird (wenn überhaupt), jegliche Antwort
Header die gesendet werden sollen, und beliebige Callbacks für Initialisierung und folgende
Bearbeitung.
Vorhandene Standard Kontexte
Standardmäßig sind zwei Kontexte im ContextSwitch Helfer
vorhanden: json und XML.
-
JSON. Der JSON
Kontext setzt den 'Content-Type' Antwort Header auf
'application/json' und den View Skript Suffix auf
'json.phtml'.
Trotzdem wird standardmäßig kein View Skript benötigt. Es serialisiert einfach
alle View Variablen und sendet die JSON Antwort sofort aus.
Dieses Verhalten kann deaktiviert werden indem die automatische
JSON Serialisierung abgeschaltet wird:
$this->_helper->contextSwitch()->setAutoJsonSerialization(false);
-
XML. Der XML Kontext
setzt den 'Content-Type' Antwort Header auf 'text/xml' und
den View Skript Suffix auf 'xml.phtml'. Es muß ein neues
View Skript für den Kontext erstellt werden.
Eigene Kontexte erstellen
Manchmal sind die Standardkontexte nicht genug. Zum Beispiel wenn man
YAML zurückgeben will, oder PHP serialisieren,
ein RSS oder ATOM Feed, usw.
ContextSwitch erlaubt es das zu tun.
Der einfachste Weg einen neuen Kontext hinzuzufügen ist über die
addContext() Methode. Diese Methoe nimmt zwei Argumente, den
Namen des Kontextes, und eine Array Spezifikation. Die Spezifikation sollte ein oder
mehrere der folgenden Dinge enthalten:
-
suffix: Der Suffix der dem Standard View Suffix angefügt
werden soll der im ViewRenderer registriert ist.
-
headers: Ein Array von Header zu Wert Paaren das als Teil
der Antwort gesendet werden soll.
-
callbacks: Ein Array das ein oder mehrere der Schlüssel
'init' oder 'post' enthält, die auf gültige PHP Callbacks
zeigen und die für die Initialisierung des Contextes und die Nachbearbeitung
verwendet werden können.
Initialisierungs Callbacks treten auf wenn der Kontext durch
ContextSwitch erkannt wird. Sie können verwendet werden um
spezielle Logik auszuführen die stattfinden soll. Als Beispiel verwendet der
JSON Kontext einen Callback um den ViewRenderer auszuschalten
wenn die automatische JSON Serialisierung eingeschaltet ist.
Nachbearbeitung tritt wärend der postDispatch()
Routine der Aktion auf, und kann verwendet werden um spezielle Logik
auszuführen. Als Beispiel verwendet der JSON Kontext einen
Callback um festzustellen ob die automatische JSON
Serialisierung eingeschaltet ist; wenn dem so ist, serialisiert es die View
Variablen zu JSON und sendet die Antwort, aber wenn dem nicht
so ist, schaltet es den ViewRenderer wieder ein.
Es gibt eine Vielzahl an Methoden für die Interaktion mit Kontexten:
-
addContext($context, array $spec): Fügt einen neuen
Kontext hinzu. Wirft eine Ausnahme wenn der Kontext bereits existiert.
-
setContext($context, array $spec): Fügt einen neuen
Kontext hinzu oder überschreibt einen bestehenden Kontext. Verwendet die gleiche
Spezifikation wie addContext().
-
addContexts(array $contexts): Fügt viele Kontexte auf
einmal hinzu. Das $contexts Array sollte ein Array von
Kontext zu Spezifikation Paaren sein. Wenn einer der Kontexte bereits existiert,
wird eine Ausnahme geworfen.
-
setContexts(array $contexts): Fügt neue Kontexte hinzu
und überschreibt bestehende. Verwendet die gleiche Spezifikation wie
addContexts().
-
hasContext($context): Gibt TRUE
zurück wenn der Kontext existiert, andernfalls FALSE.
-
getContext($context): Empfängt einen einzelnen Kontext
durch den Namen. Gibt ein Array zurück das der Spezifikation folgt die in
addContext() verwendet wird.
-
getContexts(): Empfängt alle Kontexte. Gibt ein Array
von Kontext zu Spezifikation Paaren zurück.
-
removeContext($context): Entfernt einen einzelnen
Kontext durch seinen Namen. Gibt im Erfolgsfall TRUE
zurück, und FALSE wenn der Kontext nicht gefunden wurde.
-
clearContexts(): Entfernt alle Kontexte.
Kontexte per Aktion setzen
Es gibt zwei Mechanismen für das Setzen vorhandener Kontexte. Es kann entweder manuell
ein Array im Controller erstellt werden, oder es können verschiedene Methoden in
ContextSwitch verwendet werden um Sie zu bauen.
Die prinzipielle Methode für das Hinzufügen von Aktion zu Kontext Relationen ist
addActionContext(). Sie erwartet zwei Argumente, die Aktion zu
welcher der Kontext hinzugefügt werden soll, und entweder den Namen des Kontextes oder
ein Array von Kontexten. Als Beispiel nehmen wir die folgende Controller Klasse an:
class FooController extends Zend_Controller_Action
{
public function listAction()
{
}
public function viewAction()
{
}
public function commentsAction()
{
}
public function updateAction()
{
}
}
Angenommen wir sollen einen XML Kontext zu der 'list' Aktion
hinzufügen, und XML und JSON Kontexte zu der
'comments' Aktion. Wir können das in der init() Methode
machen:
class FooController extends Zend_Controller_Action
{
public function init()
{
$this->_helper->contextSwitch()
->addActionContext('list', 'xml')
-> addActionContext('comments', array('xml', 'json'))
->initContext();
}
}
Alternativ kann einfach die Array-Eigenschaft $contexts definiert
werden:
class FooController extends Zend_Controller_Action
{
public $contexts = array(
'comments' => array('xml', 'json')
);
public function init()
{
$this->_helper->contextSwitch()->initContext();
}
}
Das obige ist weniger Overhead, aber enthält auch potentielle Fehler.
Die folgenden Methoden können verwendet werden um die Kontext-Mappings zu erstellen:
-
addActionContext($action, $context): markiert einen
oder mehrere Kontexte als in einer Aktion vorhanden. Wenn bereits Mapping
existieren wird einfach bei diesen Mappings angehängt.
$context kann ein einzelner Kontext sein, oder ein Array von
Kontexten.
Ein Wert von TRUE für den Kontext markiert alle vorhandenen
Kontexte als vorhanden für die Aktion.
Ein leerer Wert für $context deaktiviert alle Kontexte für
die gegebene Aktion.
-
setActionContext($action, $context): markiert einen
oder mehrere Kontexte als in einer Aktion vorhanden. Wenn bereits Mappings
existieren werden Sie mit den spezifizierten ersetzt.
$context kann ein einzelner Kontext sein, oder ein Array von
Kontexten.
-
addActionContexts(array $contexts): fügt mehrere
Aktion zu Kontext Paare auf einmal hinzu. $contexts sollte
ein assoziatives Array von Aktion zu Kontext Paaren sein. Es entspricht
addActionContext(), was bedeutet das wenn eine Paarung
bereits existiert, diese hinzugefügt wird.
-
setActionContexts(array $contexts): fungiert wie
addActionContexts(), überschreibt aber bestehende
Aktion zu Kontext Paare.
-
hasActionContext($action, $context): ermittelt ob eine
spezielle Aktion einen gegebenen Kontext hat.
-
getActionContexts($action = null): gibt entweder alle
Kontexte für eine gegebene Aktion zurück, oder alle Aktion zu Kontext Paare.
-
removeActionContext($action, $context): entfernt ein
oder mehrere Kontexte von einer gegebenen Aktion. $context
kann ein einzelner Kontext sein, oder ein Array von Kontexten.
-
clearActionContexts($action = null): entfernt alle
Kontexte von einer gegebenen Aktion, oder von allen Aktionen mit Kontexten.
Kontext Switching initialisieren
Um Kontext Switching zu initialisieren, muß initContext() im
Action Controller aufgerufen werden:
class NewsController extends Zend_Controller_Action
{
public function init()
{
$this->_helper->contextSwitch()->initContext();
}
}
In einigen Fällen, will man einen Kontext erzwingen der verwendet werden soll; zum
Beispiel wenn man nur den XML Kontext erlauben will wenn Kontext
Switching aktiviert ist. Das kann durch die Übergaben des Kontextes zu
initContext() getan werden:
$contextSwitch->initContext('xml');
Zusätzliche Funktionalitäten
Eine Vielzahl an Methoden kann verwendet werden um das Verhalten des
ContextSwitch Helfers zu verändern. Diese sind:
-
setAutoJsonSerialization($flag): Standardmäßig
serialisieren JSON Kontexte alle View Variablen in die
JSON Notierung und geben diese als Antwort zurück. Wenn man
seine eigene Antwort erstellen will, sollte das ausgeschaltet werden; das muß
vor dem Aufruf von initContext() geschehen.
$contextSwitch->setAutoJsonSerialization(false);
$contextSwitch->initContext();
Der Wert des Flags erhält man mit
getAutoJsonSerialization().
-
setSuffix($context, $suffix,
$prependViewRendererSuffix): Mit
dieser Methode kann ein anderer Suffix spezifiziert werden der für einen
gegebenen Kontext verwendet werden soll. Das dritte Argument wird verwendet um
anzuzeigen ob der aktuelle Suffix des ViewRenderers dem neuen Suffix
vorangestellt werden soll oder nicht; dieses Flag ist standardmäßig aktiviert.
Die Übergabe eines leeren Werte an den Suffix führt dazu das nur der Suffix des
ViewRenderers verwendet wird.
-
addHeader($context, $header, $content): Fügt einen
Antwort Header für einen gegebenen Kontext hinzu. $header
ist der Headername, und $content ist der Wert der an diesen
Header übergeben werden soll.
Jeder Kontxt kann mehrere Header haben; addHeader()
fügt zusätzliche Header in den Header Stack des Kontextes ein.
Wenn der spezifizierte $header bereits für diesen Kontext
existiert, wird eine Ausnahme geworfen.
-
setHeader($context, $header, $content):
setHeader() funktioniert wie
addHeader(), ausser das sie erlaubt das
existierende Kontext Header überschrieben werden.
-
addHeaders($context, array $headers): Fügt einen
gegebenen Kontext mehrere Header auf einmal hinzu. Entspricht
addHeader(), was bedeutet das eine Ausnahme geworfen
wird wenn der Header bereits existiert. $headers ist ein
Array von Header zu Kontext Paaren.
-
setHeaders($context, array $headers.): Wie
addHeaders(), nur das es
setHeader() entspricht und damit das Überschreiben
existierender Header erlaubt.
-
getHeader($context, $header): Enpfängt den Wert eines
Headers für einen gegebenen Kontext. Gibt NULL zurück wenn
dieser nicht gefunden wird.
-
removeHeader($context, $header): Entfernt einen
einzelnen Header für einen gegebenen Kontext.
-
clearHeaders($context, $header): Entfernt alle Header
für einen gegebenen Kontext.
-
setCallback($context, $trigger, $callback): Setzt
einen Callback bei einem gegebenen Trigger für einen gegebenen Kontext. Trigger
können entweder 'init' oder 'post' sein (was zeigt das der Callback entweder
bei der Initialisierung oder der Nachbearbeitung aufgerufen wird).
$callback sollte ein gültiger PHP
Callback sein.
-
setCallbacks($context, array $callbacks): Setzt
mehrere Callbacks für einen gegebenen Kontext. $callbacks
sollte ein Trigger zu Callback Paar sein. Aktuell sind die meisten Callbacks
die registriert werden können zwei, einer für Initialisierung und einer für die
Nachbearbeitung.
-
getCallback($context, $trigger): Empfängt einen
Callback für einen gegebenen Trigger in einem gegebenen Kontext.
-
getCallbacks($context): Empfängt alle Callbacks für
einen gegebenen Kontext. Gibt ein Array von Trigger zu Callback Paaren zurück.
-
removeCallback($context, $trigger): Entfernt einen
Callback für einen gegebenen Trigger und Kontext.
-
clearCallbacks($context): Entfernt alle Callbacks für
einen gegebenen Kontext.
-
setContextParam($name): Setzt den Anfrageparameter der
geprüft werden muß um zu entscheiden ob eine Kontextumschaltung angefragt wurde
oder nicht. Der Wert ist standardmäßig 'format', aber dieser Zugriffspunkt kann
verwendet werden um einen alternativen wert zu setzen.
getContextParam() kann verwendet werden um den
aktuellen Wert zu erhalten.
-
setAutoDisableLayout($flag): Standardmäßig sind
Layouts ausgeschaltet wenn eine Kontextumschaltung erfolgt; das ist weil
Layouts typischerweise dafür verwendet werden um normale Antworten
darzustellen, und Sie in alternativen Kontexten keine Bedeutung haben. Wenn man
trotzdem Layouts verwenden will (möglicherweise hat man ein Layout für einen
neuen Kontext), kann dieses Verhalten mit der Übergabe eines
FALSE Wertes an
setAutoDisableLayout() geändert werden. Das sollte
aber before dem Aufruf von
initContext() geschehen.
Um den Wert dieses Flags zu erhalten, kann der Zugriffspunkt
getAutoDisableLayout() verwendet werden.
-
getCurrentContext() kann verwendet werden um
festzustellen welcher Kontext erkannt wurde, wenn überhaupt. Er gibt
NULL zurück wenn keine Kontextumschaltung stattgefunden
hat, oder wenn er aufgerufen wurde bevor initContext()
stattgefunden hat.
AjaxContext Funktionalität
Der AjaxContext Helfer erweitert
ContextSwitch, sodas alle für ContextSwitch
gelisteten Funktionalitäten in Ihm vorhanden sind. Es gibt trotzdem ein paar wichtige
Änderungen.
Zuerst, verwendet es eine andere Action Controller Eigenschaft
$ajaxable um Kontexte festzustellen. Damit kann man verschiedene
Kontexte verwenden für AJAX gegenüber normalen
HTTP Anfragen. Die verschiedenen
* ActionContext()* Methoden von
AjaxContext schreiben in diese Eigenschaft.
Zweitens, wird nur dann getriggert wenn ein XmlHttpRequest stattgefunden hat, was durch
die isXmlHttpRequest() Methode den Anfrageobjektes
festgestellt wird. Deshalb wird, wenn der Kontextparameter ('format') in der Anfrage
übergeben wird, aber die anfrage nicht als XmlHttpRequest gemacht wurde, keine
Kontextumschaltung getriggert.
Drittens, fügt der AjaxContext einen zusätzlichen,
HTML, Kontext hinzu. In diesem Kontext setzt er den Suffix auf
'ajax.phtml' um diesen Kontext von einer normalen Anfrage zu
unterscheiden. Es werden keine zusätzlichen Header zurückgegeben.
Example #4 Aktionen erlauben auf Ajax Anfragen zu antworten
In dem folgenden Beispiel erlauben wir Anfragen auf die Aktionen 'view', 'form' und
'process' auf AJAX Anfragen zu antworten. In den ersten zwei
Fällen, 'view' und 'form' wird ein HTML Teilstück zurückgegeben
mit dem die Seite aktualisiert werden soll; im letzteren wird
JSON zurückgegeben.
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()
{
// Ein einzelnes Kommentar holen um es anzuzeigen.
// Wenn AjaxContext erkannt wurde, verwendet es das
// comment/view.ajax.phtml View Skript.
}
public function formAction()
{
// Stellt die "add new comment" Form dar.
// Wenn AjaxContext erkannt wurde, verwendes es das
// comment/form.ajax.phtml View Skript.
}
public function processAction()
{
// Bearbeitet einen neuen Kommentar
// Gibt das Ergebnis als JSON zurück; fügt die Ergebnisse einfach als
// View Variablen hinzu, und JSON wird zurückgegeben.
}
}
Auf der Seite des Clients, wird die AJAX Bibliothek einfach die
Endpunkte '/comment/view',
'/comment/form', und '/comment/process'
anfragen, und den 'format' Parameter übergeben:
'/comment/view/format/html',
'/comment/form/format/html',
'/comment/process/format/json'. (Oder der Parameter
kann über den Abfrage String übergeben werden: z.B. , "?format=json".)
Angenommen die Bibliothek übergibt den 'X-Requested-With: XmlHttpRequest'
Header, dann werden diese Aktionen das richtige Antwortformat zurückgeben.
FlashMessenger
Einführung
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,
verwendet 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)
Beispiel einer standardmäßigen 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).
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();
}
}
JSON
JSON Antworten sind die Antworten der Wahl wenn mit
AJAX Anfragen gearbeitet wird die Dataset Antworten erwarten;
JSON kann sofort auf Seite des Clienten geparst werden, was zu
schneller Ausführung führt.
Der JSON Action Helfer macht verschiedene Dinge:
-
Layouts auschalten wenn sie aktuell aktiviert sind.
-
Optional ein Array von Optionen als zweites Argument an
Zend_Json::encode() übergeben. Dieses Array von Optionen
erlaubt es Layouts und Kodierungen einzuschalten indem
Zend_Json_Expr verwendet wird.
$this->_helper-> json($data, array('enableJsonExprFinder' => true));
-
Den ViewRenderer ausschalten wenn er aktiviert ist.
-
Den 'Content-Type' Antwort Header auf 'application/json'
setzen.
-
Standardmäßig, die Antwort sofort zurückgeben, ohne darauf zu warten das die Aktion
die Ausführung beendet.
Die Verwendung ist einfach: Entweder als Methode des Helfer Brokers aufrufen, oder eine der
Methoden encodeJson() oder sendJson()
aufrufen:
class FooController extends Zend_Controller_Action
{
public function barAction()
{
// einige Berechnungen durchführen...
// Die JSON Antwort senden:
$this->_helper->json($data);
// oder...
$this->_helper->json->sendJson($data);
// oder das JSON empfangen:
$json = $this->_helper->json->encodeJson($data);
}
}
Note: Layouts behalten
Wenn man ein separates Layout für JSON Antworten hat --
möglicherweise um die JSON Antworten in einer Art Kontext zu wrappen
-- akzeptiert jede Methode im JSON Helfer ein zweites, optionales
Argument: Ein Flag um Layouts zu aktivieren oder deaktivieren. Die Übergabe eines
boolschen TRUE Wertes hält Layouts aktiviert:
$this->_helper->json($data, true);
Optional kann ein Array als zweiter Parameter übergeben werden. Dieses Array kann eine
Vielzahl von Optionen enthalten, inklusive der keepLayouts Option:
$this->_helper-> json($data, array('keepLayouts' => true);
Note: Kodierung einschalten durch Verwendung von Zend_Json_Expr
Zend_Json::encode() erlaubt die Kodierung von nativen
JSON Ausdrücken indem Zend_Json_Expr
Objekte verwendet werden. Diese Option ist standardmäßig ausgeschaltet. Um diese Option
einzuschalten muß ein boolscher TRUE Wert an die
enableJsonExprFinder Option übergeben werden:
$this->_helper-> json($data, array('enableJsonExprFinder' => true);
Wenn man das durchführen will, muss man ein Array als zweite
Option übergeben. Das erlaubt es auch andere Optionen, wie zum Beispiel die
keepLayouts Option, zu kombinieren. Alle diese Optionen werden
dann an Zend_Json::encode() übergeben.
$this->_helper-> json($data, array(
'enableJsonExprFinder' => true,
'keepLayouts' => true,
));
Redirector
Einführung
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
gotoSimple($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ährend des Umleitens
verwendet werden soll.
-
setExit() kann verwendet werden um ein
exit() nach einer Umleitung zu erzwingen.
Standardmäßig ist dieser TRUE.
-
setGotoSimple() kann verwendet werden um eine Standard
URL zu setzen die verwendet wird wenn keine an
gotoSimple() übergeben wird. Verwendet die
API von
Zend_Controller_Action::_forward():
setGotoSimple($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 und 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 Basis
URL 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:
-
gotoSimple() verwendet
setGotoSimple()
( _forward()-ähnliche 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().
Beispiel für die grundsätzliche Verwendung
Example #5 Optionen setzen
Dieses Beispiel überschreibt diverse Optionen, inklusive dem Setzen des
HTTP Statuscodes und dessen Verwendung in der Umleitung ('303'),
nicht abbrechen der Umleitung und definieren einer Standard URL
die beim Umleiten verwendet wird.
class SomeController extends Zend_Controller_Action
{
/**
* Redirector - definiert zur Komplettierung des Codes
*
* @var Zend_Controller_Action_Helper_Redirector
*/
protected $_redirector = null;
public function init()
{
$this->_redirector = $this->_helper->getHelper('Redirector');
// Setzt die Standardoptionen für die Umleitung
// Da das Objekt in der Helferanwendung registriert ist,
// wird diese für alle Aktionen ab diesem Zeitpunkt relevant
$this->_redirector->setCode(303)
->setExit(false)
->setGotoSimple("this-action",
"some-controller");
}
public function myAction()
{
/* Mach was */
// Umleiten zu einer vorher definierten URL, und einen Ausstieg
// erzwingen der stattfindet sobald das getan wurde:
$this->_redirector->redirectAndExit();
return; // wird nie erreicht
}
}
Example #6 Standardwerte verwenden
Diese Beispiel nimmt an das die Standardwerte verwendet werden, was bedeutet das
jede Umleitung in einem sofortigen exit() resultiert.
// ALTERNATIVES BEISPIEL
class AlternativeController extends Zend_Controller_Action
{
/**
* Redirector - definiert zur Komplettierung des Codes
*
* @var Zend_Controller_Action_Helper_Redirector
*/
protected $_redirector = null;
public function init()
{
$this->_redirector = $this->_helper->getHelper('Redirector');
}
public function myAction()
{
/* Mach was */
$this->_redirector
->gotoUrl('/my-controller/my-action/param1/test/param2/test2');
return; // wird nie erreicht da standardmäßig gegangen und beendet wird
}
}
Example #7 Verwenden von goto()'s _forward() API
gotoSimple()'s API entspricht der von
Zend_Controller_Action::_forward(). Der primäre
Unterschied ist das Sie eine URL von den übergebenen Parametern
erstellt und das Standardformat :module/:controller/:action/*
des Standardrouters verwendet. Dann leitet es um statt die Aktion zu verketten.
class ForwardController extends Zend_Controller_Action
{
/**
* Redirector - definiert zur Komplettierung des Codes
*
* @var Zend_Controller_Action_Helper_Redirector
*/
protected $_redirector = null;
public function init()
{
$this->_redirector = $this->_helper->getHelper('Redirector');
}
public function myAction()
{
/* Mach was */
// Umleiten zu 'my-action' von 'my-controller' im aktuellen Modul,
// und verwenden der Parameter param1 => test und param2 => test2
$this->_redirector->gotoSimple('my-action',
'my-controller',
null,
array('param1' => 'test',
'param2' => 'test2'
)
);
}
}
Example #8 Verwenden von Routen die mit gotoRoute() zusammengebaut wurden
Das folgende Beispiel verwendet die assemble() Methode des
Router's um eine
URL zu erstellen die auf einem assoziativen Array von Parametern
basiert das übergeben wurde. Es nimmt an das die folgende Route registriert wurde:
$route = new Zend_Controller_Router_Route(
'blog/:year/:month/:day/:id',
array('controller' => 'archive',
'module' => 'blog',
'action' => 'view')
);
$router->addRoute('blogArchive', $route);
Angenommen ein Array hat year auf 206 gesetzt, month auf 4, day auf 24, und id auf
42, dann würde dieses eine URL wie die folgende erstellen:
/blog/2006/4/24/42.
class BlogAdminController extends Zend_Controller_Action
{
/**
* Redirector - definiert zur Komplettierung des Codes
*
* @var Zend_Controller_Action_Helper_Redirector
*/
protected $_redirector = null;
public function init()
{
$this->_redirector = $this->_helper->getHelper('Redirector');
}
public function returnAction()
{
/* Mach was */
// Umleiten zum Blog Archiv. Erstellt die folgende URL:
// /blog/2006/4/24/42
$this->_redirector->gotoRoute(
'month' => 4,
'day' => 24,
'id' => 42),
'blogArchive'
);
}
}
ViewRenderer
Einführung
Der ViewRenderer Helfer wurde designt um die folgenden Ziele
erfüllen:
-
Entfernen der Notwendigkeit View Objekte innerhalb der Controller zu
instanzieren; View Objekte werden automatisch mit dem Controller 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 Controller und
Aktionen erstellen.
-
Dem Entwickler erlauben das Standard View Rendering Optionen für alle Controller
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.
Note:
Wenn man ein _forward(),
redirect() oder 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.
Note:
Der ViewRenderer ist standardmäßig aktiviert. Man kann Ihn
über den Parameter noViewRenderer des Frontcontrollers
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 Controllers ändern will, kann das auf zwei Wegen getan werden:
-
Instanzieren und Registrieren eines eigenen
ViewRenderer Objekts und dieses an den Helfer Broker
übergeben:
$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:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer->setView($view)
->setViewSuffix('php');
API
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:
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
Das erste Mal wenn ein Aktion Controller instanziert wird, triggert er den
ViewRenderer ein View Objekt zu instanzieren. Jedes Mal wenn ein
Controller Instanziert wird, wird die init() Methode des
ViewRenderer's aufgerufen, was dazu führt das er die view
Eigenschaft des Aktion Controllers 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:
// Eine Controller 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:
$this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
Der ViewRenderer definiert auch eine Anzahl von Zugriffspunkten
um 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
Controller. Wenn er auf TRUE gesetzt wird, ruft
postDispatch() nicht automatisch
render() im aktuellen Controller 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 Controller nicht automatisch aufrufen. Diese Einstellung wird
jedesmal zurückgesetzt wenn preDispatch() aufgerufen
wird (z.B. muß dieses Flag für jeden Controller 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 Controller benannt ist
(was das Standardverhalten ist). getNoController()
empfängt den aktuellen Wert.
-
setNeverController($flag = true) ist analog zu
setNoController(), arbeitet aber auf einem globalen
Level -- z.B. wird es nicht für jede ausgeführte Aktion zurückgesetzt.
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 Controller 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
Controller aus aufzurufen:
// Rendert 'foo' statt dem aktuellen Aktion Skript
$this->_helper->viewRenderer('foo');
// Rendert form.phtml zum 'html' Antwort Segment, ohne einen Controller aus dem
// Unterverzeichnis des View Skripts zu verwenden:
$this->_helper->viewRenderer('form', 'html', true);
Note:
setRender() und direct()
stellen das View Sktript nicht dar, sondern setzen Hinweise die
postDispatch() und
render() dann verwenden wenn die View dargestellt
wird.
Der Constructor erlaubt es optional das View Objekt und
ViewRenderer Optionen zu übergeben; er akzeptiert die gleichen
Flags wie 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 Controller Verzeichnisses des
Moduls).
-
:module zeigt auf den aktuellen Modulnamen.
-
:controller zeigt auf den aktuellen Controllernamen.
-
: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 Standardspezifikation ist
:moduleDir/views. 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.
Für eine feinkörnige Kontrolle über Pfadspezifikationen kann
Zend_Filter_Inflector verwendet werden.
Im Hintergrund verwendet der ViewRenderer einen Inflector um
bereits Abstimmungen am Pfad durchzuführen. Um auf dem Inflector einzuwirken, damit
entweder ein eigener für die Verwendung gesetzt wird, oder um den Standard Inflector zu
verändern, können die folgenden Methoden verwendet werden:
-
getInflector() empfängt den Inflector. Wenn bis dahin
keiner im ViewRenderer existiert, wird dieser, anhand der
Verwendung der Standard Regeln, erstellt.
Standardmäßig verwendet dieser statische Referenzregeln für das Suffix und
Modulverzeichnis, sowie ein statisches Ziel; das erlaubt verschiedenen
ViewRenderer Eigenschaften den Inflector dynamisch zu
ändern.
-
setInflector($inflector, $reference) erlaubt das
Setzen eines eigenen Inflectors für die Verwendung mit dem
ViewRenderer. Wenn $reference
TRUE ist, setzt dieser das Suffix und Modulverzeichnis
als statische Referenz zu ViewRenderer Eigenschaften,
genauso wie das Ziel.
Note: Standard Konventionen für das Eruieren
Der ViewRenderer führt einige Pfad Normalisierungen durch um
das Eruieren von View Skripten einfacher zu machen. Die Standardregeln sind wie
folgt:
-
:module: MixedCase und camelCaseWörter werden durch
Bindestriche getrennt, und der komplette String wird auf
Kleinschreibung geändert. z.B.: "FooBarBaz" wird "foo-bar-baz".
Intern verwendet der Inflector die Filter
Zend_Filter_Word_CamelCaseToDash und
Zend_Filter_StringToLower.
-
:controller: MixedCase und camelCaseWörter werden
durch Bindestriche getrennt; Unterstriche werden in
Verzeichnistrennzeichen konvertiert, und der komplette String wird auf
Kleinschreibung geändert. Beispiele: "FooBar" wird
"foo-bar"; "FooBar_Admin" wird
"foo-bar/admin".
Intern verwendet der Inflector die Filter
Zend_Filter_Word_CamelCaseToDash,
Zend_Filter_Word_UnderscoreToSeparator und
Zend_Filter_StringToLower.
-
:action: MixedCase und camelCaseWörter werden durch
Bindestriche getrennt; nicht-anphanummerische Zeichen werden zu
Bindestrichen übersetzt, und der komplette String wird auf
Kleinschreibung geändert. Beispiele: "fooBar" wird "foo-bar"; "foo-barBaz"
wird "foo-bar-baz".
Intern verwendet der Inflector die Filter
Zend_Filter_Word_CamelCaseToDash,
Zend_Filter_PregReplace und
Zend_Filter_StringToLower.
Die letzten Teile in der ViewRenderer API sind
die Methoden für das aktuelle herausfinden von View Skript Pfaden und Rendern von
Views. Diese enthalten:
-
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.
Note:
Sobald die View zum Antwort Objekt gerendert wurde, setzt diese
noRender um irrtümliches mehrfaches rendern zum selben
View Skript zu verhindern.
Note:
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-, Controller- oder Aktionsnamen vorkommen werden mit
Bindestrichen ('-') ersetzt. Deshalb resultiert, wenn der Controllername
'foo.bar' und die Aktion 'baz:bat' ist,
die Verwendung der standard Pfad Spezifikation einen View Skript Pfad von
'foo-bar/baz-bat.phtml'.
Note:
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.
Note:
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.
Note:
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().
Grundsätzliches Beispiel der Verwendung
Example #9 Grundsätzliche Verwendung
Am einfachsten, wird einfach der ViewRenderer Helfer mit dem
Helfer Broker in der eigenen Bootstrap Datei, initialisiert und registriert, und
anschließend die Variablen in den Aktion Methoden gesetzt.
// In der Bootstrap Datei:
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
...
// 'foo' Modul, 'bar' Controller:
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,
// ist es bereits vorhanden.
public function populateAction()
{
$this->view->foo = 'bar';
}
// Rendert nichts da zu einer anderen Aktion weitergeleitet wird;
// die neue Aktion 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');
}
}
Note: Benamungs Konventionen: Wort Begrenzer in Controller- und Aktionnamen
Wenn der Controller- 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
Controllernamen 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 darstellen 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
Separation 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 Controller, wegen der Existenz eines Pfad Separators, den Namen
Bar_BazController in
Bar/BazController.php empfängt. Der ViewRenderer emuliert die
Controller Verzeichnis Hierarchie.
Example #10 Automatisches rendern ausschalten
Für einige Aktionen oder Controller, kann es gewünscht sein das automatische Rendern
auszuschalten -- zum Beispiel, wenn eine andere Art von Ausgabe
(XML, JSON, etc)
ausgegeben werden soll, oder wenn man einfach nichts ausgeben will. Es gibt zwei
Optionen: Alle Fälle von automatischem Rendern ausschalten
( setNeverRender()), oder dieses einfach für die aktuelle
Aktion ausschalten ( setNoRender()).
// Baz Controller Klasse, bar Modul:
class Bar_BazController extends Zend_Controller_Action
{
public function fooAction()
{
// Diese Sektion nicht automatisch Rendern
$this->_helper->viewRenderer->setNoRender();
}
}
// Bat Controller Klasse, Bar Modul:
class Bar_BatController extends Zend_Controller_Action
{
public function preDispatch()
{
// Die Aktionen dieses Controller nie automatisch Rendern
$this->_helper->viewRenderer->setNoRender();
}
}
Note:
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.
Example #11 Ein anderes View Skript auswählen
Einige Situationen erfordern das ein anderes Skript, als das nach der Aktion
benannte, ausgeführt wird. Zum Beispiel, wenn man einen Controller hat der Aktionen
sowohl hinzufügen als auch bearbeiten kann, und beide mit der selben 'form' View
angezeigt werden, aber mit unterschiedlichen Werten gesetzt werden. Der Skript Name
kann ganz einfach geändert werden. Entweder mit
setScriptAction(), setRender()
oder durch Aufruf des Helfers als Methode, was wiederum
setRender() ausruft.
// Bar Controller 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...
}
}
Example #12 Die resigstrierte View ändern
Was wenn ein View Objekt modifiziert werden soll -- zum Beispiel, die Helfer Pfade
ändern, oder die Kodierung? Das kann durch Modifikation des View Objekts, das im
Controller gesetzt ist, gemacht werden, oder durch herausnehmen des View Objekts
aus dem ViewRenderer; beide referenzieren auf das gleiche
Objekt.
// Bar Controller 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');
}
}
Erweiterte Beispiel der Verwendung
Example #13 Die Pfad Spezifikationen ändern
In einigen Fällen, kann man entscheiden das die standardmäßige Pfad Spezifikation
nicht den Notwendigkeiten der Seite entspricht. Zum Beispiel, wenn man einen
einzelnen Template Baum haben will zu dem man dann Zugriff für Entwickler geben kann
(das ist sehr typisch wenn man zum Beispiel » Smarty verwendet). In solchen Fällen, kann
es gewünscht sein die Spezifkiation des View Basispfades hardkodiert zu erstellen
und eine alternative Spezifikation für die Pfade der Aktions View Skripte selbst zu
erstellen.
Für die Zwecke dieses Beispiels, nehmen wir an das der Basispfad zur View
'/opt/vendor/templates' sein soll, und das die View Skripte
durch ':moduleDir/:controller/:action.:suffix' referenziert
werden sollen; wenn das noController Flag gesetzt wurde, soll
aus dem Top Level statt aus einem Unterverzeichnis gerendert werden
(':action.:suffix'). Zuletzt soll 'tpl' als View Skript Suffix
für Dateinamen verwendet werden.
/**
* In der Bootstrap Datei:
*/
// Unterschiedliche View Implmentation
$view = new ZF_Smarty();
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
$viewRenderer->setViewBasePathSpec('/opt/vendor/templates')
->setViewScriptPathSpec(':module/:controller/:action.:suffix')
->setViewScriptPathNoControllerSpec(':action.:suffix')
->setViewSuffix('tpl');
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Example #14 Mehrfache View Skripte von der gleichen Aktion rendern
Manchmal, ist es notwendig mehrfache View Skripte von einer einzelnen Aktion zu
rendern. Das ist sehr geradlinig -- einfach mehrere Aufrufe zu
render() machen:
class SearchController extends Zend_Controller_Action
{
public function resultsAction()
{
// Annahme das $this->model das aktuelle Modell ist
$this->view->results =
$this->model->find($this->_getParam('query', '');
// render() handelt standardmäßig in Vertretung zum ViewRenderer
// Rendert zuerst die Such Form und anschließend die Ergebnisse
$this->render('form');
$this->render('results');
}
public function formAction()
{
// tue nichts; der ViewRenderer bearbeitet das View Skript automatisch
}
}
Schreiben eigener Helfer
Aktions Helfer erweitern Zend_Controller_Action_Helper_Abstract,
eine abstrakte Klasse die das Basisinterface bietet und vom Helfer Broker funktionell
benötigt wird. Diese inkludiert die folgenden Methoden:
-
setActionController() wird verwendet um den aktuellen
Aktion Controller zu setzen.
-
init(), wird vom Helfer Broker wärend der
Instanzierung ausgeführt und kann verwendet werden um den Status zurückzusetzen
wenn mehrere Controller den gleichen Helfer in einer verketteten Aktion
verwenden.
-
preDispatch(), wird vor der ausführenden Aktion
gestartet.
-
postDispatch() wird ausgeführt nachdem eine Aktion
fertig ist -- selbst wenn ein preDispatch() Plugin die
Aktion abgebrochen hat. Normalerweise nützlich für das Saubermachen.
-
getRequest() empfängt das aktuelle Anfrage Objekt.
-
getResponse() empfängt das aktuelle Antwort Objekt.
-
getName() empfängt den Helfernamen. Sie empfängt die
Portion des Klassennamens der dem letzten Unterstrich-Zeichen folgt, oder
andererseits den kompletten Klassennamen. Als Beispiel, wenn die Klasse
Zend_Controller_Action_Helper_Redirector heißt, wird
Redirector zurückgegeben; eine Klasse die
FooMessage heißt wird einfach sich selbst zurückgeben.
Optional kann eine direct() Methode in der eigenen Helfer
Klasse inkludiert werden. Wenn Sie definiert ist, erlaubt Sie den Helfer als eine
Methode des Helfer Brokers zu verwenden, um eine einfache rein-raus Verwendung des
Helfers zu ermöglichen. Als Beispiel definiert der Umleiter
direct() als einen Alias von goto()
und erlaubt damit die Verwendung des Helfers wie folgt:
// Umleiten zu /blog/view/item/id/42
$this->_helper-> redirector('item', 'view', 'blog', array('id' => 42));
Intern schaut die __call() Methode des Helfer Brokers nach
einem Helfer der redirector heißt, prüft anschließend ob der
Helfer eine definierte direct() Methode besitzt und ruft diese
mit den angegebenen Argumenten auf.
Wenn eine eigene Helfer Klasse erstellt wurde, kann man zu Ihr wie im obigen Kapitel
beschrieben, Zugang erhalten.
|
|