2.3. Zend_Cache Frontends
Zurück | Kapitel 2. Zend_Cache | Weiter

## 2.3. Zend_Cache Frontends

### 2.3.1. Zend_Cache_Core

#### 2.3.1.1. Einführung

`Zend_Cache_Core` ist ein spezielles Frontend, weil es der Kern dieses Moduls ist. Es ist ein Generelles Cache Frontend und ist durch andere Klassen erweiterbar.

| Anmerkung
Alle Frontends sind von `Zend_Cache_Core` abgeleitet so das deren Methoden und Optionen (wie folgt beschrieben) auch in anderen Frontends vorhanden sind, deswegen werden Sie dort nicht dokumentiert.

#### 2.3.1.2. Mögliche Optionen

Diese Optionen werden der Factory Methode übergeben wie im nachfolgenden Beispiel demonstriert.

Tabelle 2.1. Mögliche Optionen

Option | Daten Typ | Standardwert | Beschreibung
--- | --- | --- | ---
`caching` | `boolean` | `true` | Ein- / Ausschalten vom Caching (Kann sehr nützlich sein, für das debuggen von gecachten Skripten)
`lifeTime` | `int` | `3600` | Cache Lebensdauer (in Sekunden), wenn auf `null` gesetzt ist der Cache für immer gültig.
`logging` | `boolean` | `false` | Wenn auf true gesetzt, wird das Logging durch `Zend_Log` aktiviert (aber das System wird langsamer)
`writeControl` | `boolean` | `true` | Ein- / Ausschalten der Schreibkontrolle (der Cace wird gelesen gleich nachdem er geschrieben wurde, um fehlerhafte Einträge zu finden); das Einschalten der Schreibkontrolle wird das Schreiben des Caches etwas verlangsamen aber nicht das Lesen des Caches (es können defekte Cache Dateien entdeckt werden, aber es ist keine perfekte Kontrolle)
`automaticSerialization` | `boolean` | `false` | Ein- / Ausschalten der automatischen Serialisierung, kann dafür benutzt werden um Daten direkt zu speichern welche keine Strings sind (aber es ist langsamer)
`automaticCleaningFactor` | `int` | `0` | Ausschalten / Abgleichen des automatischen Löschprozesses (Garbage Collector): 0 heißt keine automatische Löschung des Caches, 1 heißt Systematische Cache Löschung und x > 1 heißt automatisches zufälliges Löschen 1 mal nach x Schreiboperationen.

#### 2.3.1.3. Beispiele

Ein Beispiel wird ganz am Anfang des Handbuches gegeben.

Wenn nur Strings in den Cache gespeichert werden (weil mit der "automaticSerialization" Option wäre es möglich Booleans zu speichern), kann ein kompakterer Weg wie folgt gewählt werden:

    <?php

    // Es wird angenommen das $cache existiert

    $id = 'myBigLoop'; // Die Cache ID von dem "das gecached werden soll"

    if (!($data = $cache->get($id))) {
        // Cache miss

        $data = '';
        for ($i = 0; $i < 10000; $i++) {
            $data = $data . $i;
        }

        $cache->save($data);

    }

    // [...] Irgendwas mit $data machen (Ausgeben, verarbeiten, usw.)

    ?>

Wenn mehrere Blöcke von Daten oder Daten Instanzen gecached werden sollen, ist die Idee dahinter die gleiche:

    <?php

    // Sicherstellen das Eindeutige Identifizierer verwendet werden:
    $id1 = 'foo';
    $id2 = 'bar';

    // Block 1
    if (!($data = $cache->get($id1))) {
        // Cache miss

        $data = '';
        for ($i=0;$i<10000;$i++) {
            $data = $data . $i;
        }

        $cache->save($data);

    }
    echo($data);

    // Hier wird NIE gecached
    echo('NIE GECACHED! ');

    // Block 2
    if (!($data = $cache->get($id2))) {
        // Cache miss

        $data = '';
        for ($i=0;$i<10000;$i++) {
            $data = $data . '!';
        }

        $cache->save($data);

    }
    echo($data);

    ?>

### 2.3.2. Zend_Cache_Frontend_Output

#### 2.3.2.1. Einführung

`Zend_Cache_Frontend_Output` ist ein Ausgabe-Empfangendes Frontend. Es verwendet den Ausgabe Puffer in PHP um alles zwischen der `start()` und der `end()` Methode zu fangen.

#### 2.3.2.2. Mögliche Optionen

Dieses Frontend hat keine bestimmten Optionen zusätzlich zu denen von `Zend_Cache_Core`.

#### 2.3.2.3. Beispiele

Ein Beispiel wird ganz am Anfang des Handbuches gegeben. Hier ist es mit kleinen Änderungen:

    <?php

    // Wenn es ein Cache Miss ist, wird das puffern der Ausgabe ausgelöst
    if(!$cache->start('mypage')):

    // Alle wie gewohnt ausgeben
    echo 'Hallo Welt! ';
    echo 'Das wird gecached ('.time().') ';

    $cache->end(); // Ausgabepufferung beenden
    endif;

    echo 'Hier wird nie gecached ('.time().').';

    ?>

Die Verwendung dieser Form ist ziemlich einfach um Ausgabe caching in einem bereits bestehenden Projekt, mit nur wenig oder gar keinen Codeänderungen, zu erhalten.

### 2.3.3. Zend_Cache_Frontend_Function

#### 2.3.3.1. Einführung

`Zend_Cache_Frontend_Function` cached das Ergebnis von Funktionsaufrufen. Es hat eine einzelne Hauptmethode genannt `call()` welche den Funktionsnamen und Parameter für den Aufruf, in einem Array, entgegennimmt.

#### 2.3.3.2. Mögliche Optionen

Tabelle 2.2. Mögliche Optionen

Option | Daten Typ | Standardwert | Beschreibung
--- | --- | --- | ---
`cacheByDefault` | `boolean` | `true` | Wenn true, wird der Funktionsaufruf standardmäßig gecached
`cachedFunctions` | `array` |  | Funktionsnamen die immer gecached werden sollen
`nonCachedFunctions` | `array` |  | Funktionsnamen die nie gecached werden sollen

#### 2.3.3.3. Beispiele

Die Verwendung der `call()` Funktion ist die gleiche wie die von `call_user_func_array()` in PHP:

    <?php

    $cache->call('veryExpensiveFunc', $params);

    # $params ist ein Array
    # Zum Beispiel fürs Aufrufen (mit cachen) von veryExpensiveFunc(1, 'foo', 'bar'), wird
    # $cache->call('veryExpensiveFunc', array(1, 'foo', 'bar')) benutzt

    ?>

`Zend_Cache_Frontend_Function` ist elegant genug um beides zu cachen, den Rückgabewert der Funktion und deren interne Ausgabe.

| Anmerkung
Man kann jede eingebaute oder benutzerdefinierte Funktion übergeben, mit ausnahme von `array()`, `echo()`, `empty()`, `eval()`, `exit()`, `isset()`, `list()`, `print()` und `unset()`.

### 2.3.4. Zend_Cache_Frontend_Class

#### 2.3.4.1. Einführung

`Zend_Cache_Frontend_Class` ist unterschiedlich zu `Zend_Cache_Frontend_Function` weil es das Cachen von Objekten und Statischen Methodenaufrufen erlaubt.

#### 2.3.4.2. Mögliche Optionen

Tabelle 2.3. Mögliche Optionen

Option | Daten Typ | Standardwert | Beschreibung
--- | --- | --- | ---
`cachedEntity` (Notwendig) | `mixed` |  | Wenn auf einen Klassen Namen gesetzt, wird eine abstrakte Klasse gecached und es werden statische Aufrufe verwendet; Wenn auf ein Objekt gesetzt, wird deren Objektmethoden gecached
`cacheByDefault` | `boolean` | `true` | Wenn true, wird der Aufruf standardmäßig gecached
`cachedMethods` | `array` |  | Methodennamen die immer gecached werden sollen
`nonCachedMethods` | `array` |  | Methodennamen die nie gecached werden sollen

#### 2.3.4.3. Beispiele

zum Beispiel, um einen Statischen Aufruf zu cachen :

    <?php

    class test {

        # Statische Methode
        public static function foobar($param1, $param2) {
            echo "foobar_output($param1, $param2)";
            return "foobar_return($param1, $param2)";
        }

    }

    // [...]
    $frontendOptions = array(
        'cachedEntity' => 'test' // Der Name der Klasse
    );
    // [...]

    # Der gecachte Aufruf
    $res = $cache->foobar('1', '2');

    ?>

Um klassische Methodenaufrufe zu cachen :

    <?php

    class test {

        private $_string = 'Hallo !';

        public function foobar2($param1, $param2) {
            echo($this->_string);
            echo "foobar2_output($param1, $param2)";
            return "foobar2_return($param1, $param2)";
        }

    }

    // [...]
    $frontendOptions = array(
        'cachedEntity' => new test() // Eine Instanz der Klasse
    );
    // [...]

    # Der gecachte Aufruf
    $res = $cache->foobar2('1', '2');

    ?>

### 2.3.5. Zend_Cache_Frontend_File

#### 2.3.5.1. Einführung

`Zend_Cache_Frontend_File` ist ein Frontend angetrieben durch den Änderungszeitpunkt einer "Masterdatei". Es ist wirklich interessant für Beispiele in Konfigurations- oder Templateanwendungen.

Zum Beispiel eine XML Konfigurationsdatei welche von einer Funktion geparsed wird, und die ein "Config Objekt" zurückgibt (wie durch `Zend_Config`). Mit `Zend_Cache_Frontend_File` kann das "Config Objekt" im Cache gespeichert werden (um zu Verhindern, das die XML Konfiguration jedes mal geparsed wird), aber mit einer strengen Abhängigkeit zur "Masterdatei". Wenn also die XML Konfigurationsdatei geändert wird, wird der Cache sofort ungültig.

#### 2.3.5.2. Mögliche Optionen

Tabelle 2.4. Mögliche Optionen

Option | Daten Typ | Standardwert | Beschreibung
--- | --- | --- | ---
`masterFile (mandatory)` | `string` | `` | Der komplette Pfad und Name der Master Datei

#### 2.3.5.3. Beispiele

Die Verwendung dieses Frontends ist die gleiche wie die von `Zend_Cache_Core`. Es gibt kein eigenes Beispiel - was als einziges gemacht werden muß, ist das `masterFile` zu definieren, wenn die Factory verwendet wird.

### 2.3.6. Zend_Cache_Frontend_Page

#### 2.3.6.1. Einführung

`Zend_Cache_Frontend_Page` ist wie `Zend_Cache_Frontend_Output` aber entwickelt für eine komplette Seite. Es ist unmöglich `Zend_Cache_Frontend_Page` nur für das cachen eines einzelnen Blockes zu verwenden.

Andererseits wird die "Cache ID" automatisch berechnet mit `$_SERVER['REQUEST_URI']` und (abhängig von den Optionen) mit `$_GET`, `$_POST`, `$_SESSION`, `$_COOKIE`, `$_FILES`. Trotzdem muß nur eine Methode aufgerufen werden (`start()`) weil der Aufruf von `end()` immer voll automatisch ist wenn die Seite endet.

Zur Zeit ist es nicht eingebaut, aber es ist ein HTTP abhängiges System geplant um Bandbreiten zu sparen (Das System wird ein HTTP 304 nicht geändert schicken wenn der Cache gefunden wurde und wenn der Browser bereits eine gültige Version hat).

| Anmerkung
Zend_Cache_Frontend_Page ist wirklich "Alpha Version" und ist zukünftig für Verbesserungen vorgesehen.

#### 2.3.6.2. Mögliche Optionen (Für dieses Frontend in der Zend_Cache Factory)

Tabelle 2.5. Mögliche Optionen

Option | Daten Typ | Standardwert | Beschreibung
--- | --- | --- | ---
`httpConditional` | `boolean` | `false` | Verwendung des httpConditional Systems (zur Zeit nicht implementiert)
`cacheWith{Get,Post,Session,Files,Cookie}Variables` | `boolean` | `false` | Wenn true, ist der Cache eingeschaltet, selbst wenn einige Variablen im entsprechenden Superglobalen Array sind; Wenn false, ist der Cache ausgeschaltet, wenn einige Variablen im entsprechenden Superglobalen Array sind
`makeIdWith{Get,Post,Session,Files,Cookie}Variables` | `boolean` | `true` | Wenn true, wird der Inhalt des entsprechenden Superglobalen Arrays verwendet im die Cache ID zu erstellen Wenn false, wird die Cache ID nicht vom Inhalt des Superglobalen Arrays abhängig sein

#### 2.3.6.3. Beispiele

Die Verwendung von Zend_Cache_Frontend_Page ist wirklich trivial :

    <?php

    // [...] // Benötigt, Konfiguration und Factory

    $cache->start();
    # Wenn der Cache gefunden wurde, wird das ergebnis zum Browser geschickt, und das Skript stoppt hier

    // Rest der Seite ...

    ?>

Zurück | Nach oben | Weiter
2.2. Die Theorie des Cachens | Zum Anfang | 2.4. Zend_Cache Backends