Das Response Objekt ist das logische Gegenstück zum Request Objekt. Sein Zweck ist es, Inhalte und / oder Header zu vereinigen, um sie in einem Rutsch zu versenden. Zusätzlich übergibt der Front Controller alle aufgefangenen Ausnahmen an das Response Objekt, um dem Entwickler das Verarbeiten von Ausnahmen zu ermöglichen. Dies Funktionalität kann durch Setzen von Zend_Controller_Front::throwExceptions(true) überschrieben werden. throwExceptions(true); ]]> Um die Ausgabe der Response, inklusiver der gesetzten Header, zu senden, verwendet man sendResponse(): sendResponse(); ]]> Standardmäßig ruft der Front Controller sendResponse() auf wenn er die Anfrage fertig bearbeitet hat; typischerweise wird es nie notwendig sein Ihn aufzurufen. Wenn man trotzdem die Antwort manipulieren will oder Sie beim Testen verwenden will, kann dieses Verhalten durch das Setzen des returnResponse Flags mit Zend_Controller_Front::returnResponse(true) geändert werden: returnResponse(true); $response = $front->dispatch(); // ein bischen mehr verarbeiten, wie z.B. loggen... // und dann die Ausgabe senden: $response->sendResponse(); ]]> Entwickler sollten das Response Objekt in ihren Aktionscontrollern verwenden. Statt die Ausgabe direkt zu machen und Header zu versenden, sollten diese an des Response Objekt übergeben werden: getResponse() ->setHeader('Content-Type', 'text/html') ->appendBody($content); ]]> Dadurch werden alle Header in einem Rutsch versendet, genau vor der Anzeige des Inhalts. Wenn die View Integration des Aktion Controllers verwendet wird muß der bearbeitete Inhalt des View Skripts im Antwort Objekt nicht gesetzt werden, da die Zend_Controller_Action::render() das standardmäßig macht. Sollte in der Anwendung eine Ausnahme auftreten, überprüft man den isException() Schalter des Response Objektes und erhält die Ausnahme durch Verwendung von getException(). Zusätzlich kann man ein eigenes Response Objekt erstellen, dass zu einer Fehlerseite umleitet, die Nachricht der Ausnahme loggt, die Nachricht der Ausnahme schön formatiert ausgibt (für Entwicklungsumgebungen), usw. Man kann das Response Objekt im Anschluß an die dispatch() Methode des Front Controllers erhalten oder den Front Controller auffordern, dass Response Objekt zurückzugeben statt den Inhalt auszugeben. dispatch(); $response = $front->getResponse(); if ($response->isException()) { // log, mail, etc... } // Oder den Front Controller dispatch Prozess auffordern, es zurück zu geben $front->returnResponse(true); $response = $front->dispatch(); // mach irgend was... // zum Schluß, gib die Antwort aus $response->sendResponse(); ]]> Standardmäßig werden Ausnahmennachrichten nicht ausgegeben. Dieses Verhalten kann durch den Aufruf von renderException() überschrieben werden oder indem der Front Controller aufgefordert wird, die Exceptions durch throwExceptions() auszuwerfen, wie oben gezeigt: renderExceptions(true); $front->dispatch($request, $response); // oder: $front->returnResponse(true); $response = $front->dispatch(); $response->renderExceptions(); $response->sendResponse(); // oder: $front->throwExceptions(true); $front->dispatch(); ]]> Wie vorher besprochen, ist einer der Aspekte der Antwort Objekt Aufgaben das Sammeln und Abschicken der HTTP Antwort Header. Eine Vielzahl von Methoden existieren hierfür: canSendHeaders() wird verwendet um zu ermitteln ob bereits Header gesendet wurden. Sie nimmt ein zusätzliches Flag das zeigt ob eine Ausnahme geworfen werden soll oder nicht, wenn bereits Header gesendet wurden. Das kann durch das Setzen der Eigenschaft headersSentThrowsException zu FALSE überschrieben werden. setHeader($name, $value, $replace = false) wird verwendet um einen individuellen Header zu setzen. Standardmäßig, ersetzt das keinen bereits existierenden gleichnamigen Header im Objekt; Trotzdem wird das Setzen von $replace zu true es forcieren das zu tun. Bevor der Header setzt wird, prüft er mit canSendHeaders() um zu sehen ob diese Operation zu diesem Zeitpunkt erlaubt ist, und erzwingt das eine Ausnahme geworfen wird. setRedirect($url, $code = 302) setzt einen HTTP Location Header für eine Umleitung. Wenn ein HTTP Status Code angegeben wurde, wird dieser Status Code verwendet. Intern wird setHeader() mit dem $replace Flag aufgerufen um sicherzustellen das nur ein solcher Header jemals gesendet wird. getHeaders() gibt ein Array aller Header zurück. Jedes Array Element ist ein Array mit den Schlüsseln 'name' und 'value'. clearHeaders() löscht alle registrierten Headern. setRawHeader() kann verwendet werden um Header zu setzen die keine Schlüssel/Werte Paare sind, wie einen HTTP Status Header. getRawHeaders() gibt jeden registrierten rohen Header zurück. clearRawHeaders() löscht jeden registrierten rohen Header. clearAllHeaders() löscht beide, reguläre Schlüssel/Werte Header genauso wie rohe Header. Zusätzlich zu den obigen Methoden, gint es Accessors für das Setzen und Empfangen der HTTP Antwort Codes für die aktuellen Anfrage, setHttpResponseCode() und getHttpResponseCode(). Das Antwort Objekt unterstützt "benannte Segmente". Das erlaubt es den Inhalt des Bodys in verschiedene Segmente zu isolieren und diese Segmente zu reihen damit die Ausgabe in einer spezifizierten Reihenfolge zurückgegeben wird. Intern wird der Inhalt der Bodys in einem Array gespeichert und die verschiedenen Accessor Methoden können verwendet werden um die Plazierung und Benamung innerhalb des Arrays zu indizieren. Als Beispiel könnte ein preDispatch() Hook verwendet werden um dem Antwort Objekt einen Header hinzuzufügen, dann den Aktion Controller einen Inhalt des Bodys hinzufügen zu lassen und einen postDispatch() Hook einen Footer hinzufügen zu lassen: getResponse(); $view = new Zend_View(); $view->setBasePath('../views/scripts'); $response->prepend('header', $view->render('header.phtml')); } public function postDispatch(Zend_Controller_Request_Abstract $request) { $response = $this->getResponse(); $view = new Zend_View(); $view->setBasePath('../views/scripts'); $response->append('footer', $view->render('footer.phtml')); } } // Ein Beispiel Aktion Controller class MyController extends Zend_Controller_Action { public function fooAction() { $this->render(); } } ]]> Im obigen Beispiel wird ein Aufruf zu /my/foo den endgültigen Inhalt des Bodys des Antwort Objekts mit der folgenden Struktur verursachen: ..., // Header Inhalt 'default' => ..., // Body Inhalt von MyController::fooAction() 'footer' => ... // Footer Inhalt ); ]]> Wenn das gerendert wird, wird es in der Reihenfolge gerendert in dem die Elements im Array angeordnet sind. Eine Vielzahl von Methoden kann verwendet werden um die benannten Segmente zu manipulieren: setBody() und appendBody() erlauben das ein zweiter Wert, $name, übergeben wird der ein benanntes Segment indiziert. In jedem Fall wird, wenn das übergeben wird, das spezifizierte benannte Segment überschrieben oder es wird erstellt wenn es nicht existiert (standardmäßig dem Array hinzugefügt). Wenn kein benanntes Segment an setBody() übergeben wird, resetiert es den kompletten Inhalt des Body Arrays. Wenn kein benanntes Segment an appendBody() übergeben wird, wird der Inhalt dem Wert im 'default' benannten Segment hinzugefügt. prepend($name, $content) erstellt ein $name benanntes Segment und plaziert dieses ab Beginn des Arrays. Wenn das Segment bereits existiert, wird es vor der Operation entfernt (bzw, überschrieben und getauscht). append($name, $content) erstellt ein $name benanntes Segment und plaziert es am Ende des Arrays. Wenn das Segment bereits existiert, wird es vor der Operation entfernt (bzw, überschrieben und getauscht). insert($name, $content, $parent = null, $before = false) erstellt ein $name benanntes Segment. Wenn ein $parent Segment angegeben wurde, wird das neue Segment entweder vor oder nach diesem Segment im Array plaziert (basierend auf dem Wert von $before). Wenn das Segment bereits existiert, wird es vor der Operation entfernt (bzw, überschrieben und getauscht). clearBody($name = null) entfernt ein einzelnes benanntes Segment wenn ein $name angegeben wurde (andernfalls das komplette Array). getBody($spec = false) kann verwendet werden um ein einzelnes Array Segment zu erhalten wenn $spec der Name des benannten Segments ist. Wenn $spec false ist, gibt es einen String zurück der erstellt wird durch zusammenfügen aller benannten Segmente in Ihrer Reihenfolge. Wenn $spec true ist, gibt er das Array des Body Inhalts zurück. Wie vorher beschrieben werden Ausnahmen standardmäßig wärend des Dispatchens gefangen und im Antwort Objekt registriert. Ausnahmen werden in einem Stack registriert, der es erlaubt alle Ausnahmen geworfen zu lassen -- Anwendungs Ausnahmen, Dispatch Ausnahmen, Plugin Ausnahmen, usw. Wenn man auf bestimmte Ausnahmen prüfen will oder Ausnahmen loggen will, muß man die Ausnahme API des Antwort Objekts verwenden: setException(Exception $e) erlaubt es eine Ausnahme zu registrieren. isException() sagt ob eine Ausnahme bereits registriert wurde. getException() gibt den kompletten Ausnahme Stack zurück. hasExceptionOfType($type) erlaub es festzustellen ob eine Ausnahme einer speziellen Klasse im Stack vorhanden ist. hasExceptionOfMessage($message) erlaubt es festzustellen ob eine Ausnahme mit einer speziellen Nachricht im Stack vorhanden ist. hasExceptionOfCode($code) erlaubt es festzustellen ob eine Ausnahme mit einem bestimmten Code im Stack vorhanden ist. getExceptionByType($type) erlaubt es alle Ausnahmen einer speziellen Klasse vom Stack zu erhalten. False wird zurückgegeben wenn keine gefunden wurden, und andernfalls ein Array mit Ausnahmen. getExceptionByMessage($message) erlaubt es alle Ausnahmen mit einer speziellen Nachricht vom Stack zu erhalten. False wird zurückgegeben wenn keine gefunden wurden, und andernfalls ein Array mit Ausnahmen. getExceptionByCode($code) erlaubt es alle Ausnahmen mit einem speziellen Code vom Stack zu erhalten. False wird zurückgegeben wenn keine gefunden wurden, und andernfalls ein Array mit Ausnahmen. renderExceptions($flag) erlaubt es ein Flag zu setzen das anzeigt ob die Ausnahmen ausgegeben werden sollen wenn die Antwort gesendet wurde, oder nicht. Der Zweck des Antwort Objekts ist es Header und Inhalte von den verschiedenen Aktionen und Plugins zu sammeln und diese an den Client zurückzugeben; zweitens sammelt es in der Reihenfolge Ihres auftretens alle Fehler (Ausnahmen), und gibt diese zurück, oder versteckt Sie vor dem Endbenutzer. Die Basis Antwort Klasse ist Zend_Controller_Response_Abstract, und jede erbende Klasse die erstellt wird sollte von dieser Klasse oder eine Ihrer Derivate erben. Die verschiedenen vorhandenen Methoden wurden in der vorhergehenden Sektion aufgezählt. Gründe um vom Antwort Objekt eine Subklasse zu erstellen beinhalten das Ändern wie eine Ausgabe zurückgegeben wird, basierend auf der Antwortumgebung (z.B., keine Header senden für CLI oder PHP-GTK Anfragen), zusätzliche Funktionalitäten um eine endgültige Ansicht zurückzugeben, basierend am Inhalt der in den benannten Segmenten gespeichert wurde, usw.