<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.session.advanced_usage">
    <title>Fortgeschrittene Benutzung</title>

    <para>
        Wärend die Beispiele für die Basisnutzung völlig akzeptierbar sind, in ihrem Weg Zend
        Framework Sessions zu Benutzen, ist auch die beste Praxis zu bedenken. Diese Sektion
        beschreibt die näheren Details von Session Handling und illustriert die fortgeschrittene
        Benutzung der <classname>Zend_Session</classname> Komponente.
    </para>

    <sect2 id="zend.session.advanced_usage.starting_a_session">
        <title>Starten einer Session</title>

        <para>
            Wenn man alle Anfragen einer Session durch <classname>Zend_Session</classname>
            bearbeitet haben will, muß die Session in der Bootstrap Datei gestartet werden:
        </para>

        <example id="zend.session.advanced_usage.starting_a_session.example">
            <title>Starten einer globalen Session</title>

            <programlisting language="php"><![CDATA[
Zend_Session::start();
]]></programlisting>
        </example>

        <para>
            Durch das Starten der Session in der Bootstrap Datei verhindert man das die Session
            gestartet werden könnte nachdem die Header an den Browser gesendet wurde, was zu einer
            Ausnahme und möglicherweise zu einer fehlerhaften Seiten im Browser führen würde. Viele
            gehobenen Features benötigen zuerst <methodname>Zend_Session::start()</methodname>.
            (Mehr dazu später in den gehobenen Features)
        </para>

        <para>
            Es gibt vier Wege eine Session zustarten wenn <classname>Zend_Session</classname>
            verwendet wird. Zwei sind falsch.
        </para>

        <orderedlist>
            <listitem>
                <para>
                    Falsch: <acronym>PHP</acronym>'s <ulink
                        url="http://www.php.net/manual/de/ref.session.php#ini.session.auto-start"><code>session.auto_start</code>
                        Einstellung</ulink> darf nicht eingeschaltet werden. Wenn keine Möglichkeit
                    besteht diese Einstellung in php.ini zu deaktivieren, und mod_php (oder
                    ähnliches) verwendet wird, und die Einstellung schon in <code>php.ini</code>
                    aktiviert ist, kann das folgende in der <code>.htaccess</code> Datei
                    (normalerweise im <acronym>HTML</acronym> Dokumenten Basisverzeichnis)
                    hinzugefügt werden:
                </para>

                <programlisting language="httpd.conf"><![CDATA[
php_value session.auto_start 0
]]></programlisting>
            </listitem>

            <listitem>
                <para>
                    Falsch: <acronym>PHP</acronym>'s <ulink
                        url="http://www.php.net/session_start"><methodname>session_start()</methodname></ulink>
                    Funktion darf nicht direkt verwendet werden. Wenn
                    <methodname>session_start()</methodname> direkt, und anschließend
                    <classname>Zend_Session_Namespace</classname> verwendet wird, wird von
                    <methodname>Zend_Session::start()</methodname> eine Ausnahme geworfen ("session
                    has already been started"). Wenn <methodname>Zend_Session::start()</methodname>
                    ausgerufen wird, nachdem <classname>Zend_Session_Namespace</classname> verwendet
                    wird oder <methodname>Zend_Session::start()</methodname> explizit verwendet
                    wird, wird ein Fehler vom Level <constant>E_NOTICE</constant> erzeugt und der
                    Aufruf wird ignoriert.
                </para>
            </listitem>

            <listitem>
                <para>
                    Richtig: Verwenden von <methodname>Zend_Session::start()</methodname>. Wenn es
                    gewünscht ist, das alle Anfragen eine Session haben und verwenden, sollte diese
                    Funktion sehr früh, direkt und entscheidungslos in der Bootstrap Datei
                    aufgerufen werden. Session haben einigen Overhead. Wenn einige Anfragen Sessions
                    benötigen aber andere Anfragen keine Sessions verwenden, dann:
                </para>

                <itemizedlist mark="opencircle">
                    <listitem>
                        <para>
                            Entscheidungslos, die <code>strict</code> Option auf
                            <constant>TRUE</constant> setzen durch Verwendung von
                            <methodname>Zend_Session::setOptions()</methodname> in der Bootstrap
                            Datei.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            Aufruf von <methodname>Zend_Session::start()</methodname> nur für die
                            Anfragen die eine Session verwenden müssen und vor jeglichen
                            <classname>Zend_Session_Namespace</classname> initiiert werden.
                        </para>
                    </listitem>

                    <listitem>
                        <para>
                            Normales verwenden von "<code>new Zend_Session_Namespace()</code>" wo es
                            benötigt wird, aber sicherstellen das davor
                            <methodname>Zend_Session::start()</methodname> ausgerufen wurde.
                        </para>
                    </listitem>
                </itemizedlist>

                <para>
                    Die Option <code>strict</code> verhindert das <code>new
                    Zend_Session_Namespace()</code> automatisch eine Session startet und dabei
                    <methodname>Zend_Session::start()</methodname> verwendet. Deshalb hilft diese
                    Option Anwendungs Entwicklern, sich für ein Design entscheiden zu können welches
                    verhindert das für bestimmte Anfragen Sessions verwendet werden, da es eine
                    Ausnahme verursachen würde wenn <classname>Zend_Session_Namespace</classname>
                    instanziiert wird, bevor <methodname>Zend_Session::start()</methodname>
                    aufgerufen wird. Entwickler sollten vorsichtig entscheiden welchen Einfluß die
                    Verwendung von <methodname>Zend_Session::setOptions()</methodname> hat, da diese
                    Optionen globale Seiteneffekte hat, in Folge der Korrespondenz der
                    darunterliegenden Optionen für ext/session.
                </para>
            </listitem>

            <listitem>
                <para>
                    Richtig: Einfach <code>new Zend_Session_Namespace()</code> instanzieren wo dies
                    auch immer notwendig ist, und die darunterliegende <acronym>PHP</acronym>
                    Session wird automatisch gestartet. Das bietet eine extrem simple Handhabung die
                    in den meisten Situationen gut funktioniert. Trotzdem ist man dann dafür
                    verantwortlich darauf zu schauen dass das erste
                    <code>new Zend_Session_Namespace()</code> passiert <emphasis>bevor</emphasis>
                    irgendeine Ausgabe (z.B. <ulink
                        url="http://www.php.net/headers_sent">HTTP headers</ulink> ) von
                    <acronym>PHP</acronym> an den Client gesendet wird, wenn standardmäßige,
                    Cookie-basierte Sessions verwendet werden (sehr empfehlenswert). Siehe <link
                        linkend="zend.session.global_session_management.headers_sent">dieses
                        Kapitel</link> für weitere Informationen.
                </para>
            </listitem>
        </orderedlist>
    </sect2>

    <sect2 id="zend.session.advanced_usage.locking">
        <title>Gesperrte Session Namensräume</title>

        <para>
            Session Namensräume können gesperrt werden um weitere Veränderungen der Daten in diesem
            Namensraum zu verhindern. Die Verwendung von <methodname>lock()</methodname> macht einen
            speziellen Namensraum nur-lesbar, <methodname>unLock()</methodname> macht einen
            nur-lesbaren Namensraum les- und schreibbar, und <methodname>isLocked()</methodname>
            prüft ob ein Namensraum vorher gesperrt wurde. Sperren sind flüchtig und bestehen nicht
            von einer Anfrage zur nächsten. Die Sperre des Namensraumes hat keinen Effekt auf
            Setz-Methoden von Objekten welche im Namensraum gespeichert sind, aber sie verhindert
            die Verwendung der Setz-Methoden des Namensraumes welche das gespeicherte Objekt direkt
            im Namensraum löschen oder ersetzen. Gleichwohl verhindert das Sperren von
            <classname>Zend_Session_Namespace</classname> Instanzen nicht die Verwendung von
            symbolischen Tabellen-Aliasen auf die gleichen Daten (siehe <ulink
                url="http://www.php.net/references">PHP references</ulink>).
        </para>

        <example id="zend.session.advanced_usage.locking.example.basic">
            <title>Sperren von Session Namensräumen</title>

            <programlisting language="php"><![CDATA[
$userProfileNamespace = new Zend_Session_Namespace('userProfileNamespace');

// marking session as read only locked
$userProfileNamespace->lock();

// unlocking read-only lock
if ($userProfileNamespace->isLocked()) {
    $userProfileNamespace->unLock();
}
]]></programlisting>
        </example>
    </sect2>

    <sect2 id="zend.session.advanced_usage.expiration">
        <title>Verfall von Namensräumen</title>

        <para>
            Limits können plaziert werden an der Lebensdauer von beidem, Namensräumen und
            individuellen Schlüsseln in Namensräumen. Normale Anwendungsfälle beinhalten das
            Durchlaufen von temporären Informationen zwischen Anfragen, und das vermindern der
            Aufdeckung von vielfältigen Sicherheitsrisiken durch das Entfernen des Zugangs zu
            potentiell sensitiven Informationen, manchmal nachdem Authentifizierung stettgefunden
            hat. Das Ende kann entweder auf abgelaufenen Sekunden oder der Anzahl von "Sprüngen"
            basieren, wobei ein Sprung für jede folgende Anfrage stattfindet.
        </para>

        <example id="zend.session.advanced_usage.expiration.example">
            <title>Beispiel für den Verfall</title>

            <programlisting language="php"><![CDATA[
$s = new Zend_Session_Namespace('expireAll');
$s->a = 'Apfel';
$s->p = 'Pfirsich';
$s->o = 'Orange';

$s->setExpirationSeconds(5, 'a'); // Der Schlüssel "a" läuft in 5 Sekunden ab

// Der komplette Namensraum läuft in 5 "Sprüngen"
$s->setExpirationHops(5);

$s->setExpirationSeconds(60);
// Der "expireAll" Namensraum wird als "abgelaufen" markiert
// sobald der erste Aufruf empfangen wurde und 60 Sekunden
// vergangen sind, oder in 5 Sprüngen, was auch immer zuerst stattfindet
]]></programlisting>
        </example>

        <para>
            Wenn mit Daten einer Session gearbeitet wird, die in der aktuellen Anfrage ablaufen,
            sollte Vorsicht beim Empfangen dieser Daten gehalten werden. Auch wenn diese Daten durch
            Referenz zurückgegeben werden, wird die Änderung derselben, diese Daten nicht über diese
            Abfrage hinweg gültig machen. Um die Zeit für das Ablaufen "zurückzusetzen", müssen die
            Daten in eine temporäre Variable geholt werden, diese im Namensraum entfernt und
            anschliessend der entsprechende Schlüssel wieder gesetzt werden.
        </para>
    </sect2>

    <sect2 id="zend.session.advanced_usage.controllers">
        <title>Kapseln von Sessions und Controller</title>

        <para>
            Namensräume können auch verwendet werden um den Zugriff auf Sessions durch Controller
            zu seperieren um Variablen vor Kontaminierung zu schützen. Zum Beispiel könnte ein
            Authentifizierungs Controller seine Session Daten von allen anderen Controllern separat
            halten um notwendigen Sicherheiten zu entsprechen.
        </para>

        <example id="zend.session.advanced_usage.controllers.example">
            <title>Session Namensräume für Controller mit automatischem Verfall</title>

            <para>
                Der folgende Code ist Teil eines Controllers der die Test Frage anzeigt und eine
                boolsche Variable initialisiert die anzeigt ob eine geschickte Antwort zur Test
                Frage akzeptiert werden sollte oder nicht. In diesem Fall wird dem Benutzer der
                Anwendung 300 Sekunden Zeit gegeben die angezeigte Frage zu beantworten.
            </para>

            <programlisting language="php"><![CDATA[
// ...
// Im Frage-View Controller
$testSpace = new Zend_Session_Namespace('testSpace');
$testSpace->setExpirationSeconds(300, 'accept_answer');
// Nur diese Variable ablaufen lassen
$testSpace->accept_answer = true;
//...
]]></programlisting>

            <para>
                Danach bestimmt der Controller der die Antworten für die Test Fragen bearbeitet ob
                eine Antwort akzeptiert wird oder nach basierend darauf ob der Benutzer die Antwort
                in der erlaubten Zeit übermittelt hat:
            </para>

            <programlisting language="php"><![CDATA[
// ...
// Im Frage-Prozess Controller
 $testSpace = new Zend_Session_Namespace('testSpace');
 if ($testSpace->accept_answer === true) {
     // innerhalb der Zeit
 }
 else {
     // nicht innerhalb der Zeit
 }
// ...
]]></programlisting>
        </example>
    </sect2>

    <sect2 id="zend.session.advanced_usage.single_instance">
        <title>Mehrfache Instanzen pro Namensraum verhindern</title>

        <para>
            Obwohl <link linkend="zend.session.advanced_usage.locking">session locking</link> einen
            guten Grad von Schutz gegen unerlaubte Verwendung von Session Daten in einem Namensraum
            bietet, bietet <classname>Zend_Session_Namespace</classname> auch die Fähigkeit die
            Erzeugung von mehreren Instanzen zu verhindern die zu einem einzelnen Namensraum
            korrespondieren.
        </para>

        <para>
            Um dieses Verhalten einzuschalten, muß <constant>TRUE</constant> als zweites Argument im
            Konstruktor angegeben werden wenn die letzte erlaubt Instanz von
            <classname>Zend_Session_Namespace</classname> erzeugt wurde. Jeder weitere Versuch den
            selben Namensraum zu instanzieren wird in einer geworfenen Ausnahme resultieren.
        </para>

        <example id="zend.session.advanced_usage.single_instance.example">
            <title>Zugriff auf Session Namensräume auf eine einzelne Instanz limitieren</title>

            <programlisting language="php"><![CDATA[
// Eine Instanz eines Namensraumes erstellen
$authSpaceAccessor1 = new Zend_Session_Namespace('Zend_Auth');

// Eine weitere Instanz des selben Namensraumes erstellen,
// aber weitere Instanzen verbieten
$authSpaceAccessor2 = new Zend_Session_Namespace('Zend_Auth', true);

// Eine Referenz erstellen ist immer noch möglich
$authSpaceAccessor3 = $authSpaceAccessor2;

$authSpaceAccessor1->foo = 'bar';

assert($authSpaceAccessor2->foo, 'bar');

try {
    $aNamespaceObject = new Zend_Session_Namespace('Zend_Auth');
} catch (Zend_Session_Exception $e) {
    echo 'Dieser Namensraum kann nicht instanziert werden da ' .
         '$authSpaceAccessor2 erstellt wurde\n';
}
]]></programlisting>
        </example>

        <para>
            Der zweite Parameter oben im Konstruktor sagt
            <classname>Zend_Session_Namespace</classname> das alle zukünftigen Instanzen mit dem
            <classname>Zend_Auth</classname> Namensraum nicht erlaubt sind. Der Versuch solche
            Instanzen zu erstellen verursacht eine Ausnahme die vom Konstruktor geworfen wird. Der
            Entwickler wird darauf aufmerksam gemacht eine Referenz zu einer Instanz des Objektes
            irgendwo zu speichern (<varname>$authSpaceAccessor1</varname>,
            <varname>$authSpaceAccessor2</varname>, oder <varname>$authSpaceAccessor3</varname> im
            obigen Beispiel), wenn der Zugriff auf den Namensraum der Session zu einer späteren Zeit
            während des selben Requests benötigt wird. Zum Beispiel, könnte ein Entwickler die
            Referenz in einer statischen Variable speichern, die Referenz zu einer <ulink
                url="http://www.martinfowler.com/eaaCatalog/registry.html">Registry</ulink>
            hinzufügen (siehe <link linkend="zend.registry">Zend_Registry</link>), oder diese
            andernfalls für andere Methoden verfügbar zu machen die Zugriff auf den Namensraum der
            Session benötigen.
        </para>
    </sect2>

    <sect2 id="zend.session.advanced_usage.arrays">
        <title>Arbeiten mit Arrays</title>

        <para>
            Durch die Vergangenheit der Implmentationen der Magischen Methoden in
            <acronym>PHP</acronym>, wird das Ändern von Arrays innerhalb eines Namensraumes nicht
            unter <acronym>PHP</acronym> Versionen vor 5.2.1 funktionieren. Wenn nur mit
            <acronym>PHP</acronym> 5.2.1 oder neuer gearbeitet wird, kann <link
                linkend="zend.session.advanced_usage.objects">zum nächsten Kapitel gesprungen</link>
            werden.
        </para>

        <example id="zend.session.advanced_usage.arrays.example.modifying">
            <title>Array Daten innerhalb eines Session Namensraumes verändern</title>

            <para>
                Das folgende illustriert wie das Problem reproduziert werden kann:
            </para>

            <programlisting language="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace();
$sessionNamespace->array = array();
// wird nicht wie gewünscht funktionieren vor PHP 5.2.1
$sessionNamespace->array['testKey'] = 1;
echo $sessionNamespace->array['testKey'];
]]></programlisting>
        </example>

        <example id="zend.session.advanced_usage.arrays.example.building_prior">
            <title>Arrays erstellen bevor es Session Speicher gab</title>

            <para>
                Wenn möglich, sollte das Problem vermieden werden indem Array nur dann im Session
                Namensraum gespeichert werden nachdem alle gewünschten Arraywerte gesetzt wurden.
            </para>

            <programlisting language="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace('Foo');
$sessionNamespace->array = array('a', 'b', 'c');
]]></programlisting>
        </example>

        <para>
            Wenn eine betroffene Version von <acronym>PHP</acronym> verwendet wird and ein Array
            modifiziert werden soll nachdem es mit einem Schlüssel für den Session Namensraum
            verbunden wurde, kann einer oder beide der folgenden Workarounds verwendet werden.
        </para>

        <example id="zend.session.advanced_usage.arrays.example.workaround.reassign">
            <title>Workaround: Ein geändertes Array neu Verbinden</title>

            <para>
                Im folgenden Code wird eine Kopie des gespeicherten Array erstellt, geändert und
                wieder dem Platz von dem die Kopie erstellt wurde zugeordnet wobei das originale
                Array überschrieben wird.
            </para>

            <programlisting language="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace();

// Das ursprüngliche Array hinzufügen
$sessionNamespace->array = array('tree' => 'apple');

// Eine Kopie des Arrays erstellen
$tmp = $sessionNamespace->array;

// Die Kopie des Arrays ändern
$tmp['fruit'] = 'peach';

// Die Kopie des Arrays wieder mit dem Namensraum der Session verknüpfen
$sessionNamespace->array = $tmp;

echo $sessionNamespace->array['fruit']; // gibt "peach" aus
]]></programlisting>
        </example>

        <example id="zend.session.advanced_usage.arrays.example.workaround.reference">
            <title>Workaround: Array das Referenz enthält speichern</title>

            <para>
                Alternativ, kann ein Array gespeichert werden das eine Referenz zum gewünschten
                Array enthält, die auf dieses dann indirekt zugegriffen werden.
            </para>

            <programlisting language="php"><![CDATA[
$myNamespace = new Zend_Session_Namespace('myNamespace');
$a = array(1, 2, 3);
$myNamespace->someArray = array( &$a );
$a['foo'] = 'bar';
echo $myNamespace->someArray['foo']; // gibt "bar" aus
]]></programlisting>
        </example>
    </sect2>

    <sect2 id="zend.session.advanced_usage.objects">
        <title>Sessions mit Objekten verwenden</title>

        <para>
             Wenn Objekte in einer <acronym>PHP</acronym> Session fixiert werden sollen, muß bedacht
             werden das diese für das Speichern <ulink
                 url="http://www.php.net/manual/de/language.oop.serialization.php">serialisiert</ulink>
             werden. Deshalb muß jedes Objekt das in einer <acronym>PHP</acronym> Session verewigt
             wurde deserialisiert werden nachdem es vom Speicher empfangen wurde. Das impliziert das
             der Entwickler sicherstellen muß das die Klassen für das verewigte Objekt definiert
             werden müssen bevor das Objekt vom Session Speicher deserialisiert wird. Wenn die
             Klasse eines unserialisierten Objektes nicht definiert wurde, wird es eine Instand von
             <code>stdClass</code>.
        </para>
    </sect2>

    <sect2 id="zend.session.advanced_usage.testing">
        <title>Verwenden von Sessions mit Unit Tests</title>

        <para>
            Zend Framework vertraut auf PHPUnit um das Testen von sich selbst zu ermöglichen. Viele
            Entwickler erweitern die existierende Sammlung von Unit Tests um den Code in deren
            Anwendungen anzudecken. Die Ausnahme "<emphasis>Zend_Session ist aktuell als nur-lesbar
            markiert</emphasis>" wird geworfen während Unit Tests durchgeführt werden, wenn
            irgendeine schreibende Methode verwendet wird nachdem Ende der Session. Trotzdem
            benötigen Unit Tests die <classname>Zend_Session</classname> verwenden besondere
            Aufmerksamkeit weil das Schließen (<methodname>Zend_Session::writeClose()</methodname>)
            oder Zerstören einer Session (<methodname>Zend_Session::destroy()</methodname>) weitere
            Änderungen oder Rücknahmen von Schlüsseln in jeder Instanz von
            <classname>Zend_Session_Namespace</classname> verhindert. Dieses Verhalten ist ein
            direktes Resultat des darunterliegenden ext/session Mechanismus und
            <acronym>PHP</acronym>'s <methodname>session_destroy()</methodname> und
            <methodname>session_write_close()</methodname> welche keinen "rückgängig machen"
            Mechanismus unterstützen um Setup/Teardown innerhalb der Unit Tests zu unterstützen.
        </para>

        <para>
            Um das Umzuarbeiten, siehe den Unit Test
            <methodname>testSetExpirationSeconds()</methodname> in <code>SessionTest.php</code> und
            <code>SessionTestHelper.php</code>, beide im <code>tests/Zend/Session</code>
            Verzeichnis, welche <acronym>PHP</acronym>'s <methodname>exec()</methodname> verwenden
            um einen eigenständigen Prozess zu starten. Der neue Prozess simuliert eine zweite
            Anfrage eines Browsers, viel genauer. Der separate Prozess beginnt mit einer "reinen"
            Session, genauso wie jede <acronym>PHP</acronym> Skript Ausführung für eine Web Anfrage.
            Auch jede Änderung in <varname>$_SESSION</varname> welche im aufrufenden Prozess gemacht
            wurde, ist im Kind-Prozess verfügbar, ermöglicht wenn der Elternprozess die Session
            beendet hat, bevor <methodname>exec()</methodname> verwendet wird.
        </para>

        <example id="zend.session.advanced_usage.testing.example">
            <title>PHPUnit Test Code der auf Zend_Session beruht</title>

            <programlisting language="php"><![CDATA[
// testen von setExpirationSeconds()
$script = 'SessionTestHelper.php';
$s = new Zend_Session_Namespace('space');
$s->a = 'apple';
$s->o = 'orange';
$s->setExpirationSeconds(5);

Zend_Session::regenerateId();
$id = Zend_Session::getId();
// Session freigeben damit der untere Prozess Sie verwenden kann
session_write_close();
sleep(4); // nicht lange genug damit die Dinge ablaufen
exec($script . "expireAll $id expireAll", $result);
$result = $this->sortResult($result);
$expect = ';a === apfel;o === orange;p === pfirsich';
$this->assertTrue($result === $expect,
    "Iterierung durch standard Zend_Session Namensraum fehlgeschlagen; " .
    "erwartet result === '$expect', aber '$result' bekommen");
sleep(2); // lange genug damit die Dinge ablaufen (insgesamt 6 Sekunden
          // warten, aber nach 5 Sekunden abgelaufen)
exec($script . "expireAll $id expireAll", $result);
$result = array_pop($result);
$this->assertTrue($result === '',
    "Iterierung durch standard Zend_Session Namensraum fehlgeschlagen; " .
    "erwartet result === '', aber '$result' bekommen)");
session_start(); // wiederherstellen der vorher eingefrorenen Session

// Das könnte in einen separaten Test abgeteilt werden, aber aktuell, wenn
// irgendwas vom darüberleigenden Test den darunterliegenden Test
// kontaminiert, ist das auch ein Fehler den wir wissen wollen.
$s = new Zend_Session_Namespace('expireGuava');
$s->setExpirationSeconds(5, 'g'); // Versuch nur einen Schlüssel im
                                  // Namensraum ablaufen zu lassen
$s->g = 'guava';
$s->p = 'peach';
$s->p = 'plum';

// Session auflösen damit der untere Prozess sie verwenden kann
session_write_close();
sleep(6); // Nicht lange genug damit die Dinge ablaufen können
exec($script . "expireAll $id expireGuava", $result);
$result = $this->sortResult($result);
session_start(); // Die bestimmte Session wiederherstellen
$this->assertTrue($result === ';p === plum',
    "Iterierung durch benannte Zend_Session Namensräume " .
    "fehlgeschlaten (result=$result)");
]]></programlisting>
        </example>
    </sect2>
</sect1>