2.3. Zend_Cache frontends
Terug | Hoofdstuk 2. Zend_Cache | Volgende

## 2.3. Zend_Cache frontends

### 2.3.1. Zend_Cache_Core

#### 2.3.1.1. Introductie

`Zend_Cache_Core` is een speciale frontend omdat het de kern van de module is. Het is een generieke cache frontend en wordt uitgebreid door andere classes.

| Opmerking
Alle frontends erven van `Zend_Cache_Core` zodat zijn methodes en opties (zoals hieronder beschreven) ook beschikbaar zijn in andere frontends, dus ze zullen hier niet worden gedocumenteerd.

#### 2.3.1.2. Beschikbare opties

Deze opties worden doorgegeven aan de factory methode zoals hierboven gedemonstreerd.

Tabel 2.1. Beschikbare opties

Optie | Data Type | Standaard Waarde | Omschrijving
--- | --- | --- | ---
`caching` | `boolean` | `true` | zet de caching aan of uit (kan handig zijn om te debuggen)
`lifeTime` | `int` | `3600` | Levensduur van de cache (in seconden), wanneer de waarde `null` is, blijft de cache altijd geldig.
`logging` | `boolean` | `false` | Wanneer dit op true staat, wordt logging via `Zend_Log` aangezet (maar wordt het systeem trager)
`writeControl` | `boolean` | `true` | Zet schrijfcontrole aan (de cache wordt direct na schrijven gelezen om corrupte records te herkennen), door writeControl aan te zetten zal de cache iets trager wegschrijven maar het lezen wordt niet trager (het kan sommige corrupte cache bestanden herkennen maar is geen perfecte controle)
`automaticSerialization` | `boolean` | `false` | Zet de automatische serialisatie aan of uit, dit kan worden gebruikt om direct informatie op te slaan dat geen string is (maar het is trager)
`automaticCleaningFactor` | `int` | `0` | Stel het automatische opschoonsysteem in (garbage collector): 0 betekent geen automatische opschoning, 1 betekent systematisch cache opschonen en x > 1 betekent willekeurig opschonen 1 keer per x schrijf operaties.

#### 2.3.1.3. Voorbeelden

Een voorbeeld wordt gegeven aan het begin van de handleiding.

Wanneer je alleen strings in de cache wil opslaan (want met "automaticSerialization" is het mogelijk ook sommige booleans op te slaan), kan je een compactere constructie gebruiken:

    <?php

    // we gaan er vanuit dat je $cache al hebt

    $id = 'mijnGroteLoop'; // cache id van "wat we willen cachen"

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

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

        $cache->save($data);

    }

    // [...] doe iets met $data (echo het, stuur het door enz.)

    ?>

Als je meerdere blokken of data instanties wilt cachen, is het idee hetzelfde:

    <?php

    // Zorg ervoor dat je unieke identifiers hebt:
    $id1 = 'foo';
    $id2 = 'bar';

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

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

        $cache->save($data);

    }
    echo($data);

    // Dit wordt niet door de cache beinvloed
    echo('NOOIT GECACHED! ');

    // blok 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. Introduction

`Zend_Cache_Frontend_Output` is an output-capturing frontend. It utilizes output buffering in PHP to capture everything between its `start()` and `end()` methods.

#### 2.3.2.2. Available options

This frontend doesn't have any specific options other than those of `Zend_Cache_Core`.

#### 2.3.2.3. Examples

An example is given in the manual at the very beginning. Here it is with minor changes:

    <?php

    // if it is a cache miss, output buffering is triggered
    if(!$cache->start('mypage')):

    // output everything as usual
    echo 'Hello world! ';
    echo 'This is cached ('.time().') ';

    $cache->end(); // output buffering ends
    endif;

    echo 'This is never cached ('.time().').';

    ?>

Using this form it is fairly easy to set up output caching in your already working project with little or no code refactoring.

### 2.3.3. Zend_Cache_Frontend_Function

#### 2.3.3.1. Introduction

`Zend_Cache_Frontend_Function` caches the results of function calls. It has a single main method named `call()` which takes a function name and parameters for the call in an array.

#### 2.3.3.2. Available options

Tabel 2.2. Available options

Option | Data Type | Default Value | Description
--- | --- | --- | ---
`cacheByDefault` | `boolean` | `true` | if true, function calls will be cached by default
`cachedFunctions` | `array` |  | function names which will always be cached
`nonCachedFunctions` | `array` |  | function names which must never be cached

#### 2.3.3.3. Examples

Using the `call()` function is the same as using `call_user_func_array()` in PHP:

    <?php

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

    # $params is an array
    # for example to call (with caching) veryExpensiveFunc(1, 'foo', 'bar'), you will use
    # $cache->call('veryExpensiveFunc', array(1, 'foo', 'bar'))

    ?>

`Zend_Cache_Frontend_Function` is smart enough to cache both the return value of the function and its internal output.

| Opmerking
You can pass any builtin or user defined function with the exception of `array()`, `echo()`, `empty()`, `eval()`, `exit()`, `isset()`, `list()`, `print()` and `unset()`.

### 2.3.4. Zend_Cache_Frontend_Class

#### 2.3.4.1. Introduction

`Zend_Cache_Frontend_Class` is different from `Zend_Cache_Frontend_Function` because it allows caching of object and static method calls.

#### 2.3.4.2. Available options

Tabel 2.3. Available options

Option | Data Type | Default Value | Description
--- | --- | --- | ---
`cachedEntity` (required) | `mixed` |  | if set to a class name, we will cache an abstract class and will use only static calls; if set to an object, we will cache this object methods
`cacheByDefault` | `boolean` | `true` | if true, calls will be cached by default
`cachedMethods` | `array` |  | method names which will always be cached
`nonCachedMethods` | `array` |  | method names which must never be cached

#### 2.3.4.3. Examples

For example, to cache static calls :

    <?php

    class test {

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

    }

    // [...]
    $frontendOptions = array(
        'cachedEntity' => 'test' // The name of the class
    );
    // [...]

    # The cached call
    $res = $cache->foobar('1', '2');

    ?>

To cache classic method calls :

    <?php

    class test {

        private $_string = 'hello !';

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

    }

    // [...]
    $frontendOptions = array(
        'cachedEntity' => new test() // An instance of the class
    );
    // [...]

    # The cached call
    $res = $cache->foobar2('1', '2');

    ?>

### 2.3.5. Zend_Cache_Frontend_File

#### 2.3.5.1. Introduction

`Zend_Cache_Frontend_File` is a frontend driven by the modification time of a "master file". It's really interesting for examples in configuration or templates issues.

For instance, you have an XML configuration file which is parsed by a function which returns a "config object" (like with `Zend_Config`). With `Zend_Cache_Frontend_File`, you can store the "config object" into cache (to avoid the parsing of the XML config file at each time) but with a sort of strong dependency on the "master file". So, if the XML config file is modified, the cache is immediatly invalidated.

#### 2.3.5.2. Available options

Tabel 2.4. Available options

Option | Data Type | Default Value | Description
--- | --- | --- | ---
`masterFile (mandatory)` | `string` | `` | the complete path and name of the master file

#### 2.3.5.3. Examples

Use of this frontend is the same than of `Zend_Cache_Core`. There is no need of a specific example - the only thing to do is to define the `masterFile` when using the factory.

### 2.3.6. Zend_Cache_Frontend_Page

#### 2.3.6.1. Introduction

`Zend_Cache_Frontend_Page` is like `Zend_Cache_Frontend_Output` but designed for a complete page. It's impossible to use `Zend_Cache_Frontend_Page` for caching only a single block.

On the other hand, the "cache id" is calculated automatically with `$_SERVER['REQUEST_URI']` and (depending on options) `$_GET`, `$_POST`, `$_SESSION`, `$_COOKIE`, `$_FILES`. More over, you have only one method to call (`start()`) because the `end()` call is fully automatic when the page is ended.

For the moment, it's not implemented but we plan to add a HTTP conditional system to save bandwith (the system will send a HTTP 304 Not Modified if the cache is hit and if the browser has already the good version).

| Opmerking
Zend_Cache_Frontend_Page is really "alpha stuff" and is meant to be improved further down the road.

#### 2.3.6.2. Available options (for this frontend in Zend_Cache factory)

Tabel 2.5. Available options

Option | Data Type | Default Value | Description
--- | --- | --- | ---
`httpConditional` | `boolean` | `false` | use the httpConditional system (not implemented for the moment)
`cacheWith{Get,Post,Session,Files,Cookie}Variables` | `boolean` | `false` | if true, cache is still on even if there are some variables in the corresponding superglobal array ; if false, cache is off if there are some variables in the corresponding superglobal array
`makeIdWith{Get,Post,Session,Files,Cookie}Variables` | `boolean` | `true` | if true, we have to use the content of the corresponding superglobal array to make a cache id if false, the cache id won't be dependent of the content of the corresponding superglobal array

#### 2.3.6.3. Examples

Use of Zend_Cache_Frontend_Page is really trivial :

    <?php

    // [...] // require, configuration and factory

    $cache->start();
    # if the cache is hit, the result is sent to the browser and the script stop here

    // rest of the page ...

    ?>

Terug | Omhoog | Volgende
2.2. De theorie van het cachencaching | Begin | 2.4. Zend_Cache backends