repo_zf1/documentation/manual/de/module_specs/Zend_Controller-Migration.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 17171 -->
<!-- Reviewed: no -->
<sect1 id="zend.controller.migration">
    <title>Migration von vorhergehenden Versionen</title>

    <para>
        Die <acronym>API</acronym> der <acronym>MVC</acronym> Komponenten hat sich mit der Zeit
        verändert. Wer Zend Framework bereits in einer früheren Version verwendet hat, folgt dem
        Leitfaden unten, damit die Skripte die neue Archtitekur verwenden.
    </para>

    <sect2 id="zend.controller.migration.fromoneseventooneeight">
        <title>Migratiion von 1.7.x zu 1.8.0 oder neuer</title>

        <sect3 id="zend.controller.migration.fromoneseventooneeight.router">
            <title>Änderungen der Standard Route</title>

            <para>
                Da übersetzte Segmente in der neuen Standard Route eingeführt wurden, ist das
                '<emphasis>@</emphasis>' Zeichen kein spezielles Zeichen am Begin eines Segments
                der Route. Um es trotzdem in einem statischen Segment verwenden zu können, muß es
                durch das Voranstellen eines zweiten '<emphasis>@</emphasis>' Zeichens escapt
                werden. Die selbe Regel trifft für das '<emphasis>:</emphasis>' Zeichen zu:
            </para>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromonesixtooneseven">
        <title>Migration von 1.6.x zu 1.7.0 oder neuer</title>

        <sect3 id="zend.controller.migration.fromonesixtooneseven.dispatcher">
            <title>Änderungen im Dispatcher Interface</title>

            <para>
                Benutzer haben uns darauf aufmerksam gemacht das
                <classname>Zend_Controller_Action_Helper_ViewRenderer</classname> Methoden auf der
                abstrakten Dispatcher Klasse verwendet hat die nicht im Dispatcher Interface waren.
                Die folgenden Methoden wurden hinzugefügt um sicherzustellen das eigene Dispatcher
                weiterhin mit den ausgelieferten Implementierungen funktionieren:
            </para>

            <itemizedlist>
                <listitem>
                    <para>
                        <methodname>formatModuleName()</methodname>: sollte verwendet werden um
                        einen rohen Controllernamen zu nehmen, wie den einen der in einem
                        Anfrageobjekt gepackt ist, und Ihn in einen richtigen Klassennamen zu
                        reformatieren den eine Klasse, die
                        <classname>Zend_Controller_Action</classname> erweitert, verwenden würde
                    </para>
                </listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonesix">
        <title>Migration von 1.5.x zu 1.6.0 oder neuer</title>

        <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
            <title>Änderungen im Dispatcher Interface</title>

            <para>
                Benutzer haben uns darauf aufmerksam gemacht das sowohl
                <classname>Zend_Controller_Front</classname> als auch
                <classname>Zend_Controller_Router_Route_Module</classname> Methoden des Dispatchers
                verwenden die nicht im Dispatcher Interface waren. Wir haben jetzt die folgenden
                drei Methoden hinzugefügt um sicherzustellen das eigene Dispatcher weiterhin mit der
                ausgelieferten Implementation arbeiten:
            </para>

            <itemizedlist>
                <listitem><para>
                    <methodname>getDefaultModule()</methodname>: Sollte den Namen des
                    Standardmoduls zurückgeben.
                </para></listitem>

                <listitem><para>
                    <methodname>getDefaultControllerName()</methodname>: Sollte den Namen des
                    Standardcontrollers zurückgeben.
                </para></listitem>

                <listitem><para>
                    <methodname>getDefaultAction()</methodname>: Sollte den Namen der
                    Standardaktion zurückgeben.
                </para></listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonefive">
        <title>Migration von 1.0.x zu 1.5.0 oder neuer</title>

        <para>
            Obwohl die meisten grundsätzlichen Funktionalitäten die gleichen bleiben und alle
            dokumentierten Funktionalitäten die gleichen bleiben gibt es doch ein spezielles
            <emphasis>undokumentiertes</emphasis> "Feature" das geändert wurde.
        </para>

        <para>
            Wenn <acronym>URL</acronym>s geschrieben werden besteht der dokumentierte Weg darin die
            Aktionsnamen camelCased mit einem Trennzeichen zu schreiben; diese sind normalerweise
            '.' oder '-', können aber im Dispatcher konfiguriert werden. Der Dispatcher ändert den
            Aktionsnamen intern auf Kleinschreibung und verwendet diese Trennzeichen um die
            Aktionsmethode wieder zu bauen indem er sie camelCase schreibt. Trotzdem, weil
            <acronym>PHP</acronym> Funktionen nicht unabhängig von der Schreibweise sind,
            <emphasis>könnte</emphasis> man <acronym>URL</acronym>s mit camelCase schreiben und der
            Dispatcher würde diese auf den gleichen Platz auflösen. Zum Beispiel, 'camel-cased'
            würde durch den Dispatcher zu 'camelCasedAction' werden; trotzdem, durch den Fall der
            unabhängigen Schreibweise in <acronym>PHP</acronym>, würden beide die selbe Methode
            ausführen.
        </para>

        <para>
            Das führt zu Problemen mit dem ViewRenderer wenn View Skripte aufgelöst werden. Der
            kanonische, dokumentierte Weg besteht darin das alle Trennzeichen zu Bindestrichen
            umgewandelt und die Wörter kleingeschrieben werden. Das erzeugt eine semantische
            Bindung zwischen Aktionen und View Skripten, und die Normalisierung stellt sicher
            das die Skripte gefunden werden. Trotzdem, wenn die Aktion 'camelCased' aufgerufen und
            aufgelöst wird, ist das Trennzeichen nicht mehr vorhanden, und der ViewRenderer
            versucht einen anderen Ort aufzulösen -- <filename>camelcased.phtml</filename> statt
            <filename>camel-cased.phtml</filename>.
        </para>

        <para>
            Einige Entwickler hängen an diesem "Feature", welches nie angedacht war. Verschiedene
            Änderungen im 1.5.0 Baum, führen dazu das der ViewRenderer diese Pfade nicht länger
            auflöst; die semantische Bindung wird nun erzwungen. Ale erstes, erzwingt der
            Dispatcher nun die Groß-/Kleinschreibung in Aktionsnamen. Das bedeutet das das
            hinleiten zu eigenen Aktionen über die URL durch Verwendung von camelCase nicht länger
            auf die gleiche Methode aufgelöst wird wie mit Trennzeichen (z.B. 'camel-casing').
            Das führt dazu das der ViewRenderer jetzt nur mehr zeichen-getrennte Aktionen
            honoriert wenn er View Skripte auflöst.
        </para>

        <para>´
            Wenn man findet das man auf dieses "Feature" nicht verzichten kann gibt es mehrere
            Optionen:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Beste Option: Die View Skripte umbenennen. Vorteile: zukünftige Kompatibilität.
                    Nachteile: Wenn man viele View Skripte hat die auf dem vorigen aufbauen führt
                    das, unerwarteter Weise, zu vielen Umbenennungen die durchgeführt werden müssen.
                </para>
            </listitem>

            <listitem>
                <para>
                    Zweitbeste Option: Der ViewRenderer delegiert nun die Auflösung von View
                    Skripten zu <classname>Zend_Filter_Inflector</classname>; man kann die Regeln
                    des Inflectors ändern damit er nicht länger die Wörter der Aktion mit einem
                    Bindestrich trennt:
                </para>

                <programlisting language="php"><![CDATA[
$viewRenderer =
    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$inflector = $viewRenderer->getInflector();
$inflector->setFilterRule(':action', array(
    new Zend_Filter_PregReplace(
        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
        ''
    ),
    'StringToLower'
));
]]></programlisting>

                <para>
                    Der obige Code ändert den Inflector so, das er Wörter nicht länger mit einem
                    Bindestrich trennt; Es kann auch gewünscht sein den 'StringToLower' Filter zu
                    entfernen man die aktuellen View Skripte camelCased benannt haben
                    <emphasis>will</emphasis>.
                </para>

                <para>
                    Wenn die Umbenennung der View Skripte zu aufwendig oder Zeitintensiv ist, dann
                    ist das die beste Option wenn man die Zeit hierfür findet.
                </para>
            </listitem>

            <listitem>
                <para>
                    Die am wenigsten zu empfehlende Option: Man kann den Dispatcher dazu zwingen
                    camelCase Aktionsnamen mit einem neuen Front Controller Flag
                    <property>useCaseSensitiveActions</property> zu bearbeiten:
                </para>

                <programlisting language="php"><![CDATA[
$front->setParam('useCaseSensitiveActions', true);
]]></programlisting>

                <para>
                    Das erlaubt es camelCase in der URL zu verwenden uns es trotzdem auf die
                    gleiche Aktion aufzulösen wie wenn Trennzeichen verwendet worden wären. Das
                    bedeutet das das Originale Problem trotzdem durchschlägt; es kann notwendig
                    sein die zweite Option von oben zusätzlich zu verwenden um sicherzustellen
                    das die Dinge in allen Variationen funktionieren.
                </para>

                <para>
                    Man sollte auch beachten das die Verwendung dieses Flags eine Notiz auslöst,
                    das dessen Verwendung nicht mehr durchgeführt werden sollte.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninethree">
        <title>Migration von 0.9.3 nach 1.0.0RC1 oder neuer</title>

        <para>
            Die prinzipiellen Änderungen die durch 1.0.0RC1 angeboten werden sind die Einführung und
            standardmäßige Aktivierung des
            <link linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
            Plugins und den
            <link linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>
            Aktionhelfer. Bitte lies die Dokumentation jedes einzelnen gründlich um zu sehen wie sie
            arbeiten und welchen Effekt Sie auf die eigene Anwendung haben können.
        </para>

        <para>
            Der <classname>ErrorHandler</classname> Plugin läuft wärend der
            <methodname>postDispatch()</methodname> Prüfung auf Ausnahmen, und leitet zu einem
            spezifizierten Fehlerhandler Controller weiter. Solch ein Controller sollte in der
            eigenen Anwendung inkludiert werden. Er kann deaktiviert werden durch das setzen des
            Frontcontroller Parameters <property>noErrorHandler</property>:
        </para>

        <programlisting language="php"><![CDATA[
$front->setParam('noErrorHandler', true);
]]></programlisting>

        <para>
            Der <classname>ViewRenderer</classname> Aktionhelfer automatisiert die Injizierung der
            View in den Aktioncontroller genauso wie das autorendern von Viewskripten basierend auf
            die aktuelle Aktion. Das primäre Problem dem man begegnen kann ist, wenn man Aktionen
            hat die keine View Skripte rendern und weder vorwärts- noch weiterleiten, da der
            <classname>ViewRenderer</classname> versucht ein View Skript zu Rendern basierend auf
            dem Aktionnamen.
        </para>

        <para>
            Es gibt verschiedene Strategien die man anwenden kann um den eigenen Code upzudaten. In
            kurzer Form, kann man global den <classname>ViewRenderer</classname> im eigenen
            Frontcontroller Bootstrap vor dem Abarbeiten ausschalten:
        </para>

        <programlisting language="php"><![CDATA[
// Annahme das $front eine Instanz von Zend_Controller_Front ist
$front->setParam('noViewRenderer', true);
]]></programlisting>

        <para>
            Trotzdem ist es keine gute Langzeitstrategie, da es auch bedeutet das man mehr Code
            schreiben muß.
        </para>

        <para>
            Wenn man bereit ist damit zu beginnen die <classname>ViewRenderer</classname>
            Funktionalität zu verwenden, gibt es verschiedene Dinge die man im eigenen
            Controllercode beachten muß. Zuerst muß auf die Aktionmethoden (die Methoden die mit
            'Action' enden) geachtet werden, und ausgesucht werden was eine jede machen soll. Wenn
            nichts vom folgenden passiert, muß man Änderungen durchführen:
        </para>

        <itemizedlist>
            <listitem>
                <para>Aufruf von <command>$this->render();</command></para>
            </listitem>
            <listitem>
                <para>Aufruf von <command>$this->_forward();</command></para>
            </listitem>
            <listitem>
                <para>Aufruf von <command>$this->_redirect();</command></para>
            </listitem>
            <listitem>
                <para>Aufruf des <classname>Redirector</classname> Aktionhelfers</para>
            </listitem>
        </itemizedlist>

        <para>
            Die einfachste Änderung ist das Ausschalten des Auto-Rendering für diese Methode:
        </para>

        <programlisting language="php"><![CDATA[
$this->_helper->viewRenderer->setNoRender();
]]></programlisting>

        <para>
            Wenn man herausfindet das keine der eigenen Aktionmethoden rendern, weiterleiten oder
            umleiten, wird man voraussichtlich die oben angeführte Zeile in die eigene
            <methodname>preDispatch()</methodname> oder <methodname>init()</methodname> Methode
            einfügen wollen:
        </para>

        <programlisting language="php"><![CDATA[
public function preDispatch()
{
    // Ausschalten des autorendern vom View Skript
    $this->_helper->viewRenderer->setNoRender()
    // .. andere Dinge tun...
}
]]></programlisting>

        <para>
            Wenn <methodname>render()</methodname> aufgerufen wird, und man
            <link linkend="zend.controller.modular">die konventionelle Modulare Verzeichnis
                Struktur</link> verwendet, wird man den Code ändern wollen um Autorendern zu
            Verwenden:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Wenn man mehrere View Skripte in einer einzelnen Aktion rendert muß nichts
                    geändert werden.
                </para>
            </listitem>
            <listitem>
                <para>
                    Wenn man einfach <methodname>render()</methodname> ohne Argumente aufruft,
                    können diese Zeilen entfernt werden.
                </para>
            </listitem>
            <listitem>
                <para>
                    Wenn man <methodname>render()</methodname> mit Argumenten aufruft, und danach nicht
                    irgendeine Bearbeitung durchführt oder mehrere View sktipe rendert, können diese
                    Aufrufe zu <command>$this->_helper->viewRenderer();</command> geändert
                    werden.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Wenn die konventionelle modulare Verzeichnisstruktur nicht verwendet wird, gibt es eine
            Vielzahl von Methoden für das Setzen des View Basispfades und der Skript
            Pfadspezifikationen so das man den <classname>ViewRenderer</classname> verwenden kann.
            Bitte lies die <link linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer
                Dokumentation</link> für Informationen über diese Methoden.
        </para>

        <para>
            Wenn ein View Objekt von der Registry verwendet, oder das eigene View Objekt verändert,
            oder eine andere View Implementation verwendet wird wird man den
            <classname>ViewRenderer</classname> in diesem Objekt injiziieren wollen. Das kann ganz
            einfach jederzeit durchgeführt werden.
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Vor dem Verarbeiten einer Frontcontroller Instanz:
                </para>

                <programlisting language="php"><![CDATA[
// Annahme das $view bereits definiert wurde
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
]]></programlisting>
            </listitem>

            <listitem>
                <para>
                    Jederzeit wärend des Bootstrap Prozesses:
                </para>

                <programlisting language="php"><![CDATA[
$viewRenderer =
    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer->setView($view);
]]></programlisting>
            </listitem>
        </itemizedlist>

        <para>
            Es gibt viele Wege den <emphasis>ViewRenderer</emphasis> zu modifizieren inklusive dem
            Setzen eines anderen View Skripts zum Rendern, dem Spezifizieren von Veränderungen für
            alle veränderbaren Elemente eines View Skript Pfades (inklusive der Endung), dem
            Auswählen eines Antwort-benannten Segments zur Anpassung und mehr. Wenn die
            konventionelle modulare Verzeichnisstruktur nicht verwendet wird, kann noch immer eine
            andere Pfad Spezifikation mit dem <emphasis>ViewRenderer</emphasis> zugeordnet werden.
        </para>

        <para>
            Wir empfehlen die Adaptierung des eigenen Codes um den
            <emphasis>ErrorHandler</emphasis> und <emphasis>ViewRenderer</emphasis> zu verwenden da
            diese neue Kernfunktionalitäten sind.
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninetwo">
        <title>Migration von 0.9.2 nach 0.9.3 oder neuer</title>

        <para>
            0.9.3 bietet <link linkend="zend.controller.actionhelpers">Aktionhelfer</link> neu an.
            Als Teil dieser Änderung wurden die folgenden Methoden entfernt da Sie nun im <link
                linkend="zend.controller.actionhelpers.redirector">Weiterleitungs
                Aktionhelfer</link> inkludiert sind:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <methodname>setRedirectCode()</methodname>; wurde umbenannt in
                    <methodname>Zend_Controller_Action_Helper_Redirector::setCode()</methodname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <methodname>setRedirectPrependBase()</methodname>; wurde umbenannt in
                    <methodname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</methodname>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <methodname>setRedirectExit()</methodname>; wurde umbenannt in
                    <methodname>Zend_Controller_Action_Helper_Redirector::setExit()</methodname>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Lese die <link linkend="zend.controller.actionhelpers">Aktionhelfer Dokumentation</link>
            für nähere Informationen über das empfangen und manipulieren von Helfer Objekten und die
            <link linkend="zend.controller.actionhelpers.redirector">Weiterleitungshelfer
                Dokumentation</link> für weitere Information über das setzen von
            Weiterleitungsoptionen (sowie alternative Methoden des weiterleitens).
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerosix">
        <title>Migration von 0.6.0 nach 0.8.0 oder neuer</title>

        <para>
            Durch bisherige Änderungen bleibt die wesentliche Verwendung der <acronym>MVC</acronym>
            Komponenten gleich:
        </para>

        <programlisting language="php"><![CDATA[
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/path/to/controllers');
]]></programlisting>

        <para>
            Dennoch wurde die Verzeichnisstruktur gründliche überarbeitet, verschiedene Komponenten
            wurden entfernt und mehrere andere umbenannt und hinzugefügt. Die Änderungen beinhalten:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <classname>Zend_Controller_Router</classname> wurde entfernt für den Rewrite
                    Router entfernt.
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_RewriteRouter</classname> wurde in
                    <classname>Zend_Controller_Router_Rewrite</classname> umbenannt und zum Standard
                    Router befördert, der mit dem Framework ausgeliefert wird;
                    <classname>Zend_Controller_Front</classname> wird ihn als Standard verwenden,
                    wenn kein anderer Router übergeben wird.
                </para>
            </listitem>

            <listitem>
                <para>
                    Eine neue Route Klasse für die Verwendung mit dem Rewrite Router wurde
                    eingeführt: <classname>Zend_Controller_Router_Route_Module</classname>; sie
                    deckt die Standardrouten ab, die vom <acronym>MVC</acronym> verwendet werden
                    und bietet die Unterstützung für <link
                        linkend="zend.controller.modular">Controller Module</link>.
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_Router_StaticRoute</classname> wurde umbenannt in
                    <classname>Zend_Controller_Router_Route_Static</classname>.
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_Dispatcher</classname> wurde umbenannt in
                    <classname>Zend_Controller_Dispatcher_Standard</classname>.
                </para>
            </listitem>

            <listitem>
                <para>
                    <methodname>Zend_Controller_Action::_forward()</methodname>'s Argumente wurden
                    geändert. Die Signatur ist nun:
                </para>

                <programlisting language="php"><![CDATA[
final protected function _forward($action,
                                  $controller = null,
                                  $module = null,
                                  array $params = null);
]]></programlisting>

                <para>
                    <varname>$action</varname> wird immer benötigt; wenn kein Controller angegeben
                    wird, wird eine Action im aktuellen Controller angenommen.
                    <varname>$module</varname> wird immer ignoriert, es sei denn
                    <varname>$controller</varname> wird angegeben. Schließlich werden alle
                    übergebenen Parameter <code>$params</code> an das Request Objekt angehängt.
                    Wenn man keinen Controller oder kein Modul angeben, aber dennoch Parameter
                    übergeben möchte, gibt man einfach <constant>NULL</constant> für diese Werte an.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerotwo">
        <title>Migration von 0.2.0 oder früher nach 0.6.0</title>

        <para>
            Die grundlegende Verwendung der <acronym>MVC</acronym> Komponenten hat sich nicht
            verändert; man kann immer noch das folgende machen:
        </para>

        <programlisting language="php"><![CDATA[
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/path/to/controllers');
]]></programlisting>

        <programlisting language="php"><![CDATA[
/* -- Erstelle einen Router -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user',
                  'user/:username',
                  array('controller' => 'user', 'action' => 'info')
);

/* -- Setze ihn im Controller -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- Setze da Controller Verzeichnis und starte die Verarbeitung -- */
$ctrl->setControllerDirectory('/path/to/controllers');
$ctrl->dispatch();
]]></programlisting>

        <para>
            Wir empfehlen die Verwendung des Response Objektes, um Inhalte und Header zu sammeln.
            Dies erlaubt den flexibleren Wechsel von Ausgabeformaten (z.B. <acronym>JSON</acronym>
            oder <acronym>XML</acronym> statt <acronym>XHTML</acronym>) in deiner Applikation.
            Standardmäßig verarbeitet <methodname>dispatch()</methodname> die Antwort, sendet
            Header und gibt die Inhalte aus. Man kann den Front Controller auch auffordern, die
            Antwort durch <methodname>returnResponse()</methodname> zurückzugeben und die Antwort
            dann auf eigene Weise ausgeben. Eine zukünftige Version des Front Controllers könnte
            die Verwendung des Response Objektes durch Output Buffering erzwingen.
        </para>

        <para>
            Es gibt viele weitere zusätzliche Funktionalitäten, welche die vorherige
            <acronym>API</acronym> erweitern. Diese sind in der Dokumentation aufgeführt.
        </para>

        <para>
            Die meisten Änderungen, die man beachten muss, betreffen das Erweitern der diversen
            Komponenten. Die wichtigsten davon sind:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <methodname>Zend_Controller_Front::dispatch()</methodname> fängt standardmäßig
                    die Ausnahmen im Response Objekt ab und gibt sie nicht aus, um sicherzugehen,
                    dass keine sensitiven Systeminformationen ausgegeben werden. Man kann dies auf
                    mehrere Arten überschreiben:
                </para>

                <itemizedlist>
                    <listitem>
                        <para>
                            Setzen von <methodname>throwExceptions()</methodname> im Front
                            Controller:
                        </para>
                        <programlisting language="php"><![CDATA[
$front->throwExceptions(true);
]]></programlisting>
                    </listitem>

                    <listitem>
                        <para>
                            Setzen von <methodname>renderExceptions()</methodname> im Response
                            Objekt:
                        </para>
                        <programlisting language="php"><![CDATA[
$response->renderExceptions(true);
$front->setResponse($response);
$front->dispatch();

// oder:
$front->returnResponse(true);
$response = $front->dispatch();
$response->renderExceptions(true);
echo $response;
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem>
                <para>
                    <methodname>Zend_Controller_Dispatcher_Interface::dispatch()</methodname>
                    akzeptiert und gibt nun ein <link
                        linkend="zend.controller.request">Anfrage Objekt</link> anstelle eines
                    Dispatcher Token zurück.
                </para>
            </listitem>

            <listitem>
                <para>
                    <methodname>Zend_Controller_Router_Interface::route()</methodname>
                    akzeptiert und gibt nun ein <link
                        linkend="zend.controller.request">Anfrage Objekt</link> anstelle eines
                    eines Dispatcher Token zurück.
                </para>
            </listitem>

            <listitem>
                <para><classname>Zend_Controller_Action</classname> Änderungen beinhalten:</para>

                <itemizedlist>
                    <listitem>
                        <para>
                            Der Konstruktur akzeptiert nun genau drei Argumente,
                            <classname>Zend_Controller_Request_Abstract</classname>
                            <varname>$request</varname>,
                            <classname>Zend_Controller_Response_Abstract</classname>
                            <varname>$response</varname>, und
                            <type>Array</type> <varname>$params</varname> (Optional).
                            <methodname>Zend_Controller_Action::__construct()</methodname>
                            verwendet diese, um die Request, Response und invokeArgs Eigenschaften
                            für das Objekt zu setzen, und beim Überschreiben des Konstrukturs
                            sollte man dies ebenfalls tun. Besser ist es, die
                            <methodname>init()</methodname> Methode zu verwenden, um jedwede
                            Instanzkonfiguration durchzuführen, weil diese Methode als letzte
                            Methode des Konstrukturs aufgerufen wird.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            <methodname>run()</methodname> ist nicht länger als final definiert,
                            wird aber auch nicht länger vom Front Controller verwendet; sein
                            einziger Zweck ist, dass die Klasse auch als Page Controller verwendet
                            werden kann. Sie nimmt nun zwei optionale Argument an, ein
                            <classname>Zend_Controller_Request_Abstract</classname>
                            <varname>$request</varname> und ein
                            <classname>Zend_Controller_Response_Abstract</classname>
                            <varname>$response</varname>.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            <methodname>indexAction()</methodname> muss nicht mehr länger definiert
                            werden, aber wird als Standardaktion empfohlen. Dies erlaubt dem
                            RewriteRouter und den Action Controllern andere Standardaktionsmethoden
                            zu definieren.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            <methodname>__call()</methodname> sollte überschrieben werden, um jede
                            undefinierte Aktion automatisch verarbeiten zu können.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            <methodname>_redirect()</methodname> nimmt nun ein optionales zweites
                            Argument entgegen, den <acronym>HTTP</acronym> Code, der mit dem
                            Redirect zurückgegeben werden soll, und ein optionales drittes Argument
                            <varname>$prependBase</varname>, das angibt, dass die im Request Objekt
                            registrierte Basis URL der übergebenen <acronym>URL</acronym> voran
                            gestellt werden soll.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            Die <varname>$_action</varname> Eigenschaft wird nicht mehr gesetzt.
                            Diese Eigenschaft war ein
                            <classname>Zend_Controller_Dispatcher_Token</classname>, der in der
                            aktuellen Inkarnation nicht mehr länger existiert. Der einzige Zweck
                            des Tokens war, Informationen über angeforderte Controller, Aktion und
                            <acronym>URL</acronym> Parameter bereit zu stellen. Diese Infrmationen
                            ist nun im Request Objekt verfügbar und kann wie folgt abgerufen
                            werden:
                        </para>

                        <programlisting language="php"><![CDATA[
// Hole den angeforderten Controllernamen
// Der Zugriff erfolgte bisher über: $this->_action->getControllerName().
// Das Beispiel unten verwendet getRequest(), obwohl man auch direkt auf die
// $_request Eigenschaft zugreifen kann; die Verwendung von getRequest() wird
// empfohlen, da eine Elternklasse den Zugriff auf das Request Objekt
// überschreiben könnte
$controller = $this->getRequest()->getControllerName();

// Hole den angeforderten Aktionsnamen
// Der Zugriff erfolgte bisher über: $this->_action->getActionName().
$action = $this->getRequest()->getActionName();

// Hole die Anfrageparameter
// Dies hat sich nicht verändert; die _getParams() und _getParam()
// Methoden leiten nun einfach auf das Request Objekt weiter.
$params = $this->_getParams();
// fordere den 'foo' Parameter an und verwende
// 'default', wenn kein Standardwert gefunden werden kann
$foo = $this->_getParam('foo', 'default');
]]></programlisting>
                    </listitem>

                    <listitem>
                        <para>
                            <methodname>noRouteAction()</methodname> wurde entfernt. Der geeignete
                            Weg, um nicht vorhandene Aktionsmethoden abzufangen, wenn man sie an
                            eine Standardaktion weiter leiten möchte, sollte die Verwendung von
                            <methodname>__call()</methodname> sein:
                        </para>

                        <programlisting language="php"><![CDATA[
public function __call($method, $args)
{
    // Wenn eine nicht vorhandene 'Action' Methode angefordert wurde,
    // leite auf die Standard Aktionsmethode um:
    if ('Action' == substr($method, -6)) {
        return $this->defaultAction();
    }

    throw new Zend_Controller_Exception('Invalid method called');
}
]]></programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem>
                <para>
                    <methodname>Zend_Controller_RewriteRouter::setRewriteBase()</methodname> wurde
                    entfernt. Stattdessen soll
                    <methodname>Zend_Controller_Front::setBaseUrl()</methodname> verwendet werden
                    (oder <methodname>Zend_Controller_Request_Http::setBaseUrl()</methodname>, wenn
                    die Request Klasse verwendet wird).
                </para>
            </listitem>

            <listitem>
                <para>
                    <classname>Zend_Controller_Plugin_Interface</classname> wurde durch
                    <classname>Zend_Controller_Plugin_Abstract</classname> ersetzt. Alle Methoden
                    nehmen nun ein <link linkend="zend.controller.request">Request Objekt</link>
                    statt eines Dispatcher Tokens entgegen bzw. geben es zurück.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->