Previous Next

Zend_Test_PHPUnit

Zend_Test_PHPUnit bietet einen TestCase, für MVC Anwendungen die Ausnahmen enthalten, für das Testen einer Vielzahl an Möglichkeiten. Der warscheinlich einfachste Weg um zu verstehen was das ist, ist das ansehen des folgenden Beispiels.

Example #1 Beispiel eines TestCases für ein Anwendungs Login

Das folgende ist ein einfacher TestCase für einen UserController um verschiedene Dinge zu prüfen:

  • Die Login Form sollte nicht-authenthifizierten Benutzern angezeigt werden.

  • Wenn sich ein Benutzer einloggt, sollte er zu seiner Profilseite umgeleitet werden, und diese Profilseite sollte relevante Informationen enthalten.

Dieses spezielle Beispiel nimmt ein paar Dinge an. Erstens schieben wird das meiste unseres Bootstrappings in ein Plugin. Das vereinfacht das Setup des TestCases da es uns erlaubt unsere Umgebung geziehlt zu spezifizieren, und es uns ausserdem erlaubt die Anwendung in einer einzigen Zeile zu starten. Unser spezielles Beispiel nimmt auch an das das Setup automatisch lädt sodas wir uns nicht um das laden der betreffenden Klassen kümmern müssen (wie die richtigen Kontroller, Plugins, usw).

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }

    public function appBootstrap()
    {
        $this->frontController
             ->registerPlugin(new Bugapp_Plugin_Initialize('development'));
    }

    public function testCallWithoutActionShouldPullFromIndexAction()
    {
        $this->dispatch('/user');
        $this->assertController('user');
        $this->assertAction('index');
    }

    public function testIndexActionShouldContainLoginForm()
    {
        $this->dispatch('/user');
        $this->assertAction('index');
        $this->assertQueryCount('form#loginForm', 1);
    }

    public function testValidLoginShouldGoToProfilePage()
    {
        $this->request->setMethod('POST')
              ->setPost(array(
                  'username' => 'foobar',
                  'password' => 'foobar'
              ));
        $this->dispatch('/user/login');
        $this->assertRedirectTo('/user/view');

        $this->resetRequest()
             ->resetResponse();
        $this->request->setMethod('GET')
             ->setPost(array());
        $this->dispatch('/user/view');
        $this->assertRoute('default');
        $this->assertModule('default');
        $this->assertController('user');
        $this->assertAction('view');
        $this->assertNotRedirect();
        $this->assertQuery('dl');
        $this->assertQueryContentContains('h2', 'User: foobar');
    }
}

Dieses Beispiel können auch einfacher geschrieben werden -- nicht alle der gezeigten Ausnahmen sind notwendig. Hoffentlich zeigt es wie einfach es ist die eigene Anwendung zu testen. This example could be written somewhat simpler -- not all the assertions shown are necessary, and are provided for illustration purposes only. Hopefully, it shows how simple it can be to test your applications.

Bootstrapping der eigenen TestCases

Wie im Login Beispiel gezeigt sollten alle MVC Testcases Zend_Test_PHPUnit_ControllerTestCase erweitern. Diese Klasse ihrerseits erweitert PHPUnit_Framework_TestCase, und gibt einem alle Strukturen und Ausnahmen die man von PHPUnit erwartet -- sowie einiges an Scaffolding und Ausnahme spezifisches der Zend Framework MVC Implementation.

Um die eigene MVC Anwendung zu testen muß diese ein Bootstrap ausführen. Es gibt verschiedene Wege um das zu tun, wobei alle von Ihnen sich der öffentlichen $bootstrap Eigenschaft bedienen.

Zuerst kann diese Eigenschaft so gesetzt werden das Sie auf eine Datei zeigt. Wenn das getan wurde sollte diese Datei nicht den Front Kontroller ausführen, aber stattdessen den Front Kontroller konfigurieren und alles was die Anwendung an speziellen Dingen benötigt.

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '/path/to/bootstrap/file.php'

    // ...
}

Zweitens kann ein PHP Callback angegeben werden der nach dem Bootstrap der Anwendung ausgeführt wird. Diese Methode kann im Login Beispiel gesehen werden. Wenn das Callback eine Funktion oder statische Methode ist, könnte Sie auch in der Klasse gesetzt werden:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = array('App', 'bootstrap');

    // ...
}

In Fällen in denen eine Objekt Instanz notwendig ist, empfehlen wir die Durchführung in der eigenen setUp() Methode:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        // Verwende die 'start' Methode einer Bootstrap Objekt Instanz:
        $bootstrap = new Bootstrap('test');
        $this->bootstrap = array($bootstrap, 'start');
        parent::setUp();
    }
}

Beachte das parent::setUp() aufgerufen wird; das ist notwendig, da die setUp() Methode von Zend_Test_PHPUnit_Controller_TestCase die Erinnerung des Bootstrap Prozesses durchführen wird (was den Aufruf des Callbacks inkludiert).

Wärend der normalen Anwendung wird die setUp() Methode das Bootstrap der Anwendung ausführen. Dieser Prozess wird zuerst das Löschen der Umgebung enthalten um einen reinen Anfragestatus zu erhalten, das Resetieren jedes Plugins, Helfers und Antwort Objektes. Sobald das getan wurde, wird sie anschließend die Datei laden(include) die in $bootstrap spezifiziert wurde, oder den spezifizierten Callback aufrufen.

Das Bootstrappen sollte so nahe wie möglich daran sein wie die Anwendung das Bootstrap durchführt. Trotzdem gibt es einige Fallstricke:

  • Wir bieten keine alternative Implementierung der Anfrage und Antwort Objekte; diese werden nicht verwendet. Zend_Test_PHPUnit_Controller_TestCase verwendet eigene Anfrage und Antwort Objekte, Zend_Controller_Request_HttpTestCase und Zend_Controller_Response_HttpTestCase. Diese Objekte bieten Methoden für das Konfigurieren der Anfrageumgebung auf gezieltem Wege an, und dem holen von Antwort Artefakten auf speziellem Weg.

  • Man sollte nicht erwarten Server spezielles zu testen. In anderen Worten, die Tests garantieren nicht das der Code in einer speziellen Serverkonfiguration läuft, aber das die Anwendung wie erwartet funktionieren sollte, und der Router eine gegebene Anfrage routen kann. Um das Abzuschließen sollten keine Server-speziellen Header im Anfrage Objekt gesetzt werden.

Sobald die Anwendung das Bootstrapping ausgeführt hat, kann damit begonnen werden eigene Tests zu erstellen.

Testen eigener Kontroller und MVC Anwendungen

Sobald man sein Bootstrap hat, kann man mit dem Testen beginnen. Testen funktioniert grundsätzlich wie man es in einer PHPUnit Test Suite erwarten würde, mit ein paar kleinen Unterschieden.

Zuerst muß man eine URL die getestet werden soll ausführen, indem die dispatch() Methode des TestCases ausgeführt wird:

class IndexControllerTest extends Zend_Test_PHPUnit_Controller_TestCase
{
    // ...

    public function testHomePage()
    {
        $this->dispatch('/');
        // ...
    }
}

Es gibt trotzdem Zeiten, , in denen man zusätzliche Informationen angeben muß -- GET und POST Variablen, COOKIE Informationen, usw. Man kann die Anfrage mit diesen Informationen ausstatten:

class FooControllerTest extends Zend_Test_PHPUnit_Controller_TestCase
{
    // ...

    public function testBarActionShouldReceiveAllParameters()
    {
        // Setzt GET Variablen:
        $this->request->setQuery(array(
            'foo' => 'bar',
            'bar' => 'baz',
        ));

        // Setzt POST Variablen:
        $this->request->setPost(array(
            'baz'  => 'bat',
            'lame' => 'bogus',
        ));

        // Setzt einen Cookie Wert:
        $this->request->setCookie('user', 'matthew');
        // or many:
        $this->request->setCookies(array(
            'timestamp' => time(),
            'host'      => 'foobar',
        ));

        // Setzt sogar Header:
        $this->request->setHeader('X-Requested-With', 'XmlHttpRequest');

        // Setzt die Anfrage Methode:
        $this->request->setMethod('POST');

        // Ausführung:
        $this->dispatch('/foo/bar');

        // ...
    }
}

Jetzt wurde die Anfrage durchgeführt, es ist also Zeit Ausnahmen zu prüfen.

Ausnahmen

Ausnahmen sind der Herz vom Unit Testen; Sie können verwendet werden um zu prüfen das die Ergebnisse das sind was man erwartet. Zu diesem Zweck bietet Zend_Test_PHPUnit_ControllerTestCase eine Anzahl an Ausnahmen um das testen eigene MVC Anwendungen und Kontroller einfacher zu machen.

CSS Selektor Ausnahmen

CSS Selektoren sind ein einfacher Weg um zu Prüfen das bestimmte Teile im Inhalt der Antwort enthalten sind. Mit Ihnen ist es auch trivial sicherzustellen das Elemente die für Javascript UIs und/oder AJAX Integrationen notwendig sind, vorhanden sind; die meisten JS Toolkits bieten einige Mechanismen an für das Abholen von DOM Elementen die auf CSS Selektoren basieren, so das der Syntax der gleiche wäre.

Diese Funktionalität wird über Zend_Dom_Query angeboten, und in ein Set von 'Query' Ausnahmen integriert. Jede dieser Ausnahmen nimmt als erstes Argument einen CSS Selektor, mit optional hinzugefügten Argumenten und/oder einer Fehlermeldung, basierend auf dem Ausnahmetyp. Die Regeln für das schreiben der CSS Selektoren kann im Kapitel Theorie der Anwendung von Zend_Dom_Query gefunden werden. Abfrageausnahmen enthalten:

  • assertQuery($path, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem gegebenen CSS Selektor entsprechen, vorhanden sind. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.

  • assertQueryContentContains($path, $match, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem angegebenen CSS Selektor entsprechen, vorhanden sind, und das zumindest einer dem Inhalt, der in $match angegeben wurde, entspricht. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.

  • assertQueryContentRegex($path, $pattern, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem angegebenen CSS Selektor entsprechen, vorhanden sind, und das zumindest einer dem Regulären Ausdruck der in $pattern angegeben wurde, entspricht. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.

  • assertQueryCount($path, $count, $message = ''): Nimmt an das exakt $count DOM Elemente dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.

  • assertQueryCountMin($path, $count, $message = ''): Nimmt an das zumindest $count DOM Element dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt. Achtung: Die Spezifizierung eines Wertes von 1 für $count ist das Gleiche wie die einfache Verwendung von assertQuery().

  • assertQueryCountMax($path, $count, $message = ''): Nimmt an das es nicht mehr als $count DOM Elemente gibt die dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt. Achtung: Die Spezifizierung eines Wertes von 1 für $count ist das Gleiche wie die einfache Verwendung von assertQuery().

Zusätzlich hat jede der obigen Methoden eine 'Not' Variante die eine negative Ausnahme anbietet: assertNotQuery(), assertNotQueryContentContains(), assertNotQueryContentRegex(), und assertNotQueryCount(). (Es ist zu beachten das die min und max Zählen keine dieser Varianten haben, was aus logischen Gründen so ist.)

XPath Ausnahmen

Einige Entwickler sind mit XPath vertrauter als mit CSS Selektoren, und deshalb werden für alle Query Ausnahmen auch XPath Varianten engeboten. Diese sind:

  • assertXpath($path, $message = '')

  • assertNotXpath($path, $message = '')

  • assertXpathContentContains($path, $match, $message = '')

  • assertNotXpathContentContains($path, $match, $message = '')

  • assertXpathContentRegex($path, $pattern, $message = '')

  • assertNotXpathContentRegex($path, $pattern, $message = '')

  • assertXpathCount($path, $count, $message = '')

  • assertNotXpathCount($path, $count, $message = '')

  • assertXpathCountMin($path, $count, $message = '')

  • assertNotXpathCountMax($path, $count, $message = '')

Umleitungs Ausnahmen

Oft wird eine Aktion umgeleitet. Statt der Umleitung zu folgen erlaubt es Zend_Test_PHPUnit_ControllerTestCase diese Umleitungen mit einer handvoll von Ausnahmen zu testen.

  • assertRedirect($message = ''): Nimmt einfach an das eine Umleitung stattgefunden hat.

  • assertNotRedirect($message = ''): Nimmt einfach an das keine Umleitung stattgefunden hat.

  • assertRedirectTo($url, $message = ''): Nimmt an das eine Umleitung stattgefunden hat, und das der Wert des Ziel Headers die angegebene $url ist.

  • assertNotRedirectTo($url, $message = ''): Nimmt an das eine Umleitung entweder NICHT stattgefunden hat, oder das der Wert des Ziel Headers NICHT die angegebene $url ist.

  • assertRedirectRegex($pattern, $message = ''): Nimmt an das eine Umleitung stattgefunden hat, und das der Wert des Ziel Headers dem durch $pattern angegebenen regulären Ausdruck entspricht.

  • assertNotRedirectRegex($pattern, $message = ''): Nimmt an das eine Umleitung entweder NICHT stattgefunden hat, oder das der Wert des Ziel Headers NICHT dem durch $pattern angegebenen regulären Ausdruck entspricht.

Antwort Header Ausnahmen

Zusätzlich zur Prüfung auf Umleitungs Header, ist es oft notwendig auf spezielle HTTP Antwort Codes und Header zu prüfen -- zum Beispiel, um zu erkennen um eine Aktion eine 404 oder 500 Antwort hervorruft, oder um sicherzustellen das JSON Antworten die entsprechenden Content-Type Header enthält. Die folgenden Ausnahmen sind vorhanden.

  • assertResponseCode($code, $message = ''): Nimmt an das die Antwort zum gegebenen HTTP Antwort Code geführt hat.

  • assertHeader($header, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält.

  • assertHeaderContains($header, $match, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält und das sein Inhalt den gegebenen String enthält.

  • assertHeaderRegex($header, $pattern, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält und das sein Inhalt der gegebenen Rexec entspricht.

Zusätzlich hat jede der obigen Ausnahmen eine 'Not' Variante für negative Ausnahmen.

Anfrage Ausnahmen

Es ist oft sinnvoll gegen die letzte Aktion, den Kontroller und das Modul zu prüfen; zusätzlich ist es möglich die genommene Route die prüfen. Die folgenden Ausnahmen können in diesen Fällen helfen:

  • assertModule($module, $message = ''): Nimmt an das das angegebene Modul in der letzten Dispatch Aktion verwendet wurde.

  • assertController($controller, $message = ''): Nimmt an das der angegebene Kontroller in der letzten ausgeführten Aktion ausgewählt wurde.

  • assertAction($action, $message = ''): Nimmt an das die angegebene Aktion zuletzt ausgeführt wurde.

  • assertRoute($route, $message = ''): Nimmt an das die angegebene benannte Route dem Router entsprochen hat.

Jede hat auch eine 'Not' Variante für negative Ausnahmen.

Beispiele

Zu wissen wir man die eigene Infrastruktur für Tests einstellt und wir Ausnahmen zu erstellen sind ist nur der halbe Kampf; jetzt ist es Zeit auf einige Testszenarien zu schauen und zu eruieren wie diese verwendet werden können.

Example #2 Den UserController testen

Nehmen wir einen standard Task für eine Webseite an: Authentifizierung und Registrierung von Benutzern. In unserem Beispiel definieren wir einen UserController um das zu behandeln, und haben die folgenden Notwendigkeiten:

  • Wenn ein Benutzer nicht authentifiziert ist, wird er immer zur Login Seite des Kontrollers umgeleitet, unabhängig von der spezifizierten Aktion.

  • Die Login Formularseite wird beides zeigen, das Login Formular und das Registrations Formular.

  • Die angabe von ungültigen Anmeldedaten sollte in der Rückgabe des Login Formulars resultieren.

  • Das Ansehen der Anmeldedaten sollte in einer Umleitung zur Profilseite des Benutzers resultieren.

  • Die Profilseite sollte verändert werden um den Benutzernamen des Benutzers zu enthalten.

  • Authentifizierte Benutzer welche die Loginseite besuchen sollten zu Ihrer Profilseite umgeleitet werden.

  • Bei der Abmeldung, sollten ein Benutzer zur Loginseite umgeleitet werden.

  • Mit ungültigen Daten sollte die Registrierung fehlschlagen.

Wir können, und sollten zusätzliche Tests definieren, aber diese reichen für jetzt.

Für unsere Anwendung definieren wir ein Plugin, 'Initialisieren' es, damit es bei routeStartup() läuft. Das erlaubt es uns das Bootstrapping in einem OOP Interface zu kapseln, was auch einen einfachen Weg bietet um ein Callback zu ermöglichen. Schauen wir uns erstmals die Basics dieser Klasse an:

class Bugapp_Plugin_Initialize extends Zend_Controller_Plugin_Abstract
{
    /**
     * @var Zend_Config
     */
    protected static $_config;

    /**
     * @var string Aktuelle Umgebung
     */
    protected $_env;

    /**
     * @var Zend_Controller_Front
     */
    protected $_front;

    /**
     * @var string Pfad zum Root der Anwendung
     */
    protected $_root;

    /**
     * Constructor
     *
     * Umgebung, Root Pfad und Konfiguration initialisieren
     *
     * @param  string $env
     * @param  string|null $root
     * @return void
     */
    public function __construct($env, $root = null)
    {
        $this->_setEnv($env);
        if (null === $root) {
            $root = realpath(dirname(__FILE__) . '/../../../');
        }
        $this->_root = $root;

        $this->initPhpConfig();

        $this->_front = Zend_Controller_Front::getInstance();
    }

    /**
     * Route beginnen
     *
     * @return void
     */
    public function routeStartup(Zend_Controller_Request_Abstract $request)
    {
        $this->initDb();
        $this->initHelpers();
        $this->initView();
        $this->initPlugins();
        $this->initRoutes();
        $this->initControllers();
    }

    // Die Definition von Methoden würde hier folgen...
}

Das erlaubt es uns einen Bootstrap Callback wie folgt zu erstellen:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function appBootstrap()
    {
        $controller = $this->getFrontController();
        $controller->registerPlugin(new Bugapp_Plugin_Initialize('development'));
    }

    public function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }

    // ...
}

Sobald das fertig ist, können wir unsere Tests schreiben. Trotzdem, was ist mit den Tests die erfordern das der Benutzer angemeldet ist? Die einfache Lösung besteht darin das unsere Anwendungslogik das macht... und ein bischen trickst indem die resetRequest() und resetResponse() Methoden verwendet werden, die es uns erlauben eine andere Anfrage abzusetzen.

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    // ...

    public function loginUser($user, $password)
    {
        $this->request->setMethod('POST')
                      ->setPost(array(
                          'username' => $user,
                          'password' => $password,
                      ));
        $this->dispatch('/user/login');
        $this->assertRedirectTo('/user/view');
        $this->resetRequest()
             ->resetResponse();

        $this->request->setPost(array());

        // ...
    }

    // ...
}

Jetzt schreiben wir Tests:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    // ...

    public function testCallWithoutActionShouldPullFromIndexAction()
    {
        $this->dispatch('/user');
        $this->assertController('user');
        $this->assertAction('index');
    }

    public function testLoginFormShouldContainLoginAndRegistrationForms()
    {
        $this->dispatch('/user');
        $this->assertQueryCount('form', 2);
    }

    public function testInvalidCredentialsShouldResultInRedisplayOfLoginForm()
    {
        $request = $this->getRequest();
        $request->setMethod('POST')
                ->setPost(array(
                    'username' => 'bogus',
                    'password' => 'reallyReallyBogus',
                ));
        $this->dispatch('/user/login');
        $this->assertNotRedirect();
        $this->assertQuery('form');
    }

    public function testValidLoginShouldRedirectToProfilePage()
    {
        $this->loginUser('foobar', 'foobar');
    }

    public function testAuthenticatedUserShouldHaveCustomizedProfilePage()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user/view');
        $this->assertNotRedirect();
        $this->assertQueryContentContains('h2', 'foobar');
    }

    public function
        testAuthenticatedUsersShouldBeRedirectedToProfilePageWhenVisitingLoginPage()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user');
        $this->assertRedirectTo('/user/view');
    }

    public function testUserShouldRedirectToLoginPageOnLogout()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user/logout');
        $this->assertRedirectTo('/user');
    }

    public function testRegistrationShouldFailWithInvalidData()
    {
        $data = array(
            'username' => 'This will not work',
            'email'    => 'this is an invalid email',
            'password' => 'Th1s!s!nv@l1d',
            'passwordVerification' => 'wrong!',
        );
        $request = $this->getRequest();
        $request->setMethod('POST')
                ->setPost($data);
        $this->dispatch('/user/register');
        $this->assertNotRedirect();
        $this->assertQuery('form .errors');
    }
}

Es ist zu beachten das die Tests knapp sind und, für die meisten von Ihnen, nicht den aktuellen Inhalt berücksichtigen. Stattdessen sehen Sie nach Teilen in der Anfrage -- Anfrage Codes und Header sowie DOM Knoten. Das erlaubt es schnell zu prüfen das die Strukturen wie erwartet sind -- und verhinter das die Tests jedesmal wenn der Site neue Inhalte hinzugefügt werden darin ersticken.

Es ist auch zu beachten das wir die Struktur des Dokuments in unseren Tests verwenden. Zum Beispiel schauen wir im letzten Test nach einer Form die einen Node mit der Klasse "errors" hat; das erlaubt es uns lediglich nach dem Vorhandensein von Form-Prüfungsfehlern zu testen, und uns keine Sorgen darüber zu machen warum spezielle Fehler überhaupt geworfen werden.

Diese Anwendung könnte eine Datenbank verwenden. Wenn dem so ist, muß man warscheinlich einige Grundlagen ändern um sicherzustellen das die Datenbank am Anfang jeden Tests, in einer unverfälschten, testbaren Konfiguration ist. PHPUnit bietet bereits Funktionalität um das sicherzustellen; » Lesen Sie darüber in der PHPUnit Dokumentation nach. Wir empfehlen eine separate Datenbank für das Testen zu verwenden statt der Produktionsdatenbank, und entweder eine SQLite Datei oder eine Datenbank im Speicher zu verwenden, da beide Optionen sehr performant sind, keinen separaten Server benötigen, und die meisten SQL Syntaxe verwenden können.

Previous Next
Introduction to Zend Framework
Übersicht
Installation
Zend_Acl
Einführung
Verfeinern der Zugriffskontrolle
Fortgeschrittene Verwendung
Zend_Amf
Einführung
Zend_Amf_Server
Zend_Auth
Einführung
Datenbanktabellen Authentifizierung
Digest Authentication
HTTP Authentication Adapter
LDAP Authentifizierung
Open ID Authentifikation
Zend_Cache
Einführung
Die Theorie des Cachens
Zend_Cache Frontends
Zend_Cache Backends
Zend_Captcha
Einführung
Captcha Anwendung
Captcha Adapter
Zend_Config
Einleitung
Theory of Operation
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Einführung in Getopt
Definieren von Getopt Regeln
Holen von Optionen und Argumenten
Konfigurieren von Zend_Console_Getopt
Zend_Controller
Zend_Controller Schnellstart
Zend_Controller Grundlagen
Der Front Controller
Das Request Objekt
Der Standard Router
Der Dispatcher
Action Kontroller
Action Helfer
Das Response Objekt
Plugins
Eine konventionelle modulare Verzeichnis Struktur verwenden
MVC Ausnahmen
Migration von vorhergehenden Versionen
Zend_Currency
Einführung in Zend_Currency
Arbeiten mit Währungen
Migration von vorhergehenden Versionen
Zend_Date
Einführung
Theorie der Arbeitsweise
Basis Methoden
Zend_Date API Übersicht
Erstellen von Datumswerten
Konstanten für generelle Datums Funktionen
Funktionierende Beispiele
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Debug
Variablen ausgeben
Zend_Dojo
Einführung
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helfer
Dojo Form Elemente und Dekoratore
Zend_Dom
Einführung
Zend_Dom_Query
Zend_Exception
Verwenden von Ausnahmen
Zend_Feed
Einführung
Feeds importieren
Feeds von Websites abrufen
Einen RSS Feed konsumieren
Einen Atom Feed konsumieren
Einen einzelnen Atom Eintrag konsumieren
Verändern der Feed- und Eintragsstruktur
Eigene Klassen für Feeds und Einträge
Zend_File
Zend_File_Transfer
Prüfungen für Zend_File_Transfer
Filter für Zend_File_Transfer
Migration von vorhergehenden Versionen
Zend_Filter
Einführung
Standard Filter Klassen
Filter Ketten
Filter schreiben
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Schnellstart mit Zend_Form
Erstellen von Form Elementen mit Hilfe von Zend_Form_Element
Erstellen von Form durch Verwendung von Zend_Form
Erstellen von eigenem Form Markup durch Zend_Form_Decorator
Standard Form Elemente die mit dem With Zend Framework ausgeliefert werden
Standard Form Dekoratore die mit dem Zend Framework ausgeliefert werden
Internationalisierung von Zend_Form
Fortgeschrittene Verwendung von Zend_Form
Zend_Gdata
Einführung zu Gdata
Authentifizierung mit AuthSub
Die Buchsuche Daten API verwenden
Authentifizieren mit ClientLogin
Google Kalender verwenden
Verwenden der Google Dokumente Listen Daten API
Using Google Health
Google Tabellenkalkulation verwenden
Google Apps Provisionierung verwenden
Google Base verwenden
Picasa Web Alben verwenden
Verwenden der YouTube Daten API
Gdata Ausnahmen auffangen
Zend_Http
Zend_Http_Client - Einführung
Zend_Http_Client - Fortgeschrittende Nutzung
Zend_Http_Client - Verbindungsadapter
Zend_Http_Cookie und Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Einführung
Zend_Json
Einführung
Grundlegende Verwendung
JSON Objects
XML zu JSON Konvertierung
Zend_Json_Server - JSON-RPC server
Zend_Layout
Einführung
Zend_Layout Schnellstart
Zend_Layout Konfigurations Optionen
Erweiterte Verwendung von Zend_Layout
Zend_Ldap
Einleitung
Zend_Loader
Dynamisches Laden von Dateien und Klassen
Plugins laden
Zend_Locale
Einführung
Zend_Locale verwenden
Normalisierung und Lokalisierung
Arbeiten mit Daten und Zeiten
Unterstützte Gebietsschemata
Migrieren von vorhergehenden Versionen
Zend_Log
Übersicht
Writer
Formatter
Filter
Zend_Mail
Einführung
Versand über SMTP
Versand von mehreren E-Mails über eine SMTP Verbindung
Verwendung von unterschiedlichen Versandwegen
HTML E-Mail
Anhänge
Empfänger hinzufügen
Die MIME Abgrenzung kontrollieren
Zusätzliche Kopfzeilen
Zeichensätze
Kodierung
SMTP Authentifizierung
SMTP Übertragungen sichern
Lesen von Mail Nachrichten
Zend_Measure
Einführung
Erstellung einer Maßeinheit
Ausgabe von Maßeinheiten
Manipulation von Maßeinheiten
Arten von Maßeinheiten
Zend_Memory
Übersicht
Memory Manager
Memory Objekte
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_OpenId
Einführung
Zend_OpenId_Consumer Grundlagen
Zend_OpenId_Provider
Zend_Paginator
Einführung
Verwendung
Konfiguration
Advanced usage
Zend_Pdf
Einführung
Erstellen und Laden von PDF Dokumenten
Änderungen von PDF Dokumenten speichern
Dokument Seiten
Zeichnen
Dokument Informationen und Metadaten
Anwendungsbeispiel für die Zend_Pdf Komponente
Zend_ProgressBar
Zend_ProgressBar
Zend_Registry
Die Registry verwenden
Zend_Rest
Einführung
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Überblick
Indexerstellung
Einen Index durchsuchen
Abfragesprache
Abfrage Erzeugungs API
Zeichensätze
Erweiterbarkeit
Zusammenarbeit Mit Java Lucene
Erweitert
Die besten Anwendungen
Zend_Server
Einführung
Zend_Server_Reflection
Zend_Service
Einführung
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Einführung
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Mitgelieferte Services
Zend_Service_StrikeIron: Erweiterte Verwendung
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Einführung
Grundsätzliche Verwendung
Fortgeschrittene Benutzung
Globales Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Zugriffsmethoden
AutoDiscovery
Zend_Test
Einführung
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Einführung
Arbeiten mit Zend_TimeSync
Zend_Translate
Einführung
Adapter für Zend_Translate
Benutzen von Übersetzungs Adaptoren
Migration von vorhergehenden Versionen
Zend_Uri
Zend_Uri
Zend_Validate
Einführung
Standard Prüfklassen
Kettenprüfungen
Schreiben von Prüfern
Zend_Version
Auslesen der Version des Zend Frameworks
Zend_View
Einführung
Controller Skripte
View Scripte
View Helfer
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Einführung
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework Voraussetzungen
PHP Version
PHP Erweiterungen
Zend Framework Komponenten
Zend Framework Abhängigkeiten
Zend Framework Coding Standard für PHP
Übersicht
PHP Dateiformatierung
Namens Konventionen
Code Stil
Zend Framework Performance Guide
Einführung
Laden von Klassen
Internationalisierung (I18n) und Lokalisierung (L10n)
Darstellen der View
Urheberrecht Informationen