Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend\Cache Component Proposal

Proposed Component Name Zend\Cache
Developer Notes\Cache
Proposers Marc Bennewitz
Zend Liaison TBD
Revision 1.0 - 7 March 2010: Initial Draft.
2.0 - 17 Jun 2010: finish proposal (wiki revision: 40)

Table of Contents

1. Overview

The current Zend_Cache component is very inflexible with it's Frontend/Backend structure. For example it's not possible to merge different frontends together (e.g. MasterFile and Page cache). Furthermore, few advantages of some cache storage systems are not derived by Zend_Cache. E.g. some storage systems can handle different data-types but Zend_Cache only permit strings.

Code available
Current working implementation is hosted on a branch of my Github account: Zend\Cache.
Backwards compatibility
Because the old Zend_Cache object has a complete different structure, keeping backwards compatibility is impossible.

The most of the open issues are related to this structure and should be solved with ZF 2.0 by this proposal.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will break bc 100% !!!!!
  • This components will read & write data from cache storage engines using only one adapter interface.
  • Adapters will not implement special functionalities directly to the storage engines (like serialization) to keep performance
    but implements a plugin structure to dynamically add/configure/re-order such functionalities.
  • Plugins will not store any data directly to a storage engine - a real storage adapter have to be used.
  • This component will add some special cache patterns using a different API (like PageCache, CaptureCache).

4. Dependencies on Other Framework Components


  • Zend\Loader\PluginLoader
  • Zend\Exception


  • Storage\Plugin\Serialize


  • Storage\Plugin\Filter
  • Storage\Plugin\KeyFilter

5. Theory of Operation

Storage Adapter:
The storage adapters are classes of wrappers of the existing storage engines usable for caching (Memcached, Database, Filesystem ...).
They all implement an interface to get a consistent API but only reflect supported facilities of the used storage engine.

Storage Plugins:
Precisely because the storage adapters supports different facilities you can add facilities belated with the storage plugins.
(e.g. tag support, automatic serialize). The storage plugins have the same API as the storage adapters and therefor implement
an interface extending the adapters interface. Where ever a storage adapter is required you can set an instance of a storage plugin and you can merge all storage plugins as you like. The storage plugins self don't store any data - they need a real storage adapter as storage engine.

A special storage plugin is the base storage class (Zend\Cache\Storage). It implements additional methods for simpler handling lists of
plugins within it's own instance.

Special Cache Patterns:
Some special cache patterns shouldn't use the standard cache API. They are: Output, Page, Function, Callback, Function, Class and Capture.
These caches only implement a very simple pattern interface which only defines how options have to be set.

In case of the capture pattern it no longer needs the "Static" storage adapter (or old named backend) because the storage is very specific and only usable with the capture pattern and vise versa. Therefore the capture pattern will implement reading/writing files within it's self.

6. Milestones / Tasks

  • Milestone 1: [DONE] Finish proposal
  • Milestone 2: [DONE] Working prototype
  • Milestone 3: Unit tests exist finished and component is working
  • Milestone 4: Initial documentation exists
  • Milestone 5: Changed related components
  • Milestone 6: Moved to core.

7. Class Index

Storage Adapter:

  • namespace Zend\Cache\Storage\Adapter
  • interface \Zend\Cache\Storage\Adapter
  • abstract AbstractAdapter implements Storage\Adapter
  • class Memory extends AbstractAdapter
  • class Memcached extends AbstractAdapter
  • class Apc extends AbstractAdapter
  • class WinCache extends AbstractAdapter
  • class Xcache extends AbstractAdapter
  • class ZendPlatform extends AbstractAdapter
  • class Database extends AbstractAdapter
  • class Filesystem extends AbstractAdapter
  • class SystemVShm extends AbstractZendServer
  • abstract AbstractZendServer extends AbstractAdapter
  • class ZendServerShm extends AbstractZendServer
  • class ZendServerDisk extends AbstractZendServer

Storage Plugins:

  • namespace Zend\Cache\Storage\Plugin
  • interface \Zend\Cache\Storgae\Plugin extends \Zend\Cache\Storgae\Adapter
  • abstract AbstractPlugin implements \Zend\Cache\Storgae\Plugin
  • class ClearByFactor extends AbstractPlugin
  • class ExceptionHandler extends AbstractPlugin (Callback on exception + logging)
  • class IgnoreUserAbort extends AbstractPlugin
  • class KeyFilter extends AbstractPlugin
  • class Levels extends AbstractPlugin
  • class MasterFile extends AbstractPlugin
  • class OptimizeByFactor extends AbstractPlugin
  • class Profiler extends AbstractPlugin
  • class Reluctant extends AbstractPlugin
  • class Serialize extends AbstractPlugin
  • class Tagging extends AbstractPlugin
  • class Timer extends AbstractPlugin
  • class ValueFilter extends AbstractPlugin
  • class WriteBuffer extends AbstractPlugin
  • class WriteControl extends AbstractPlugin
  • namespace \Zend\Cache
  • class Storage extends Storage\Plugin\AbstractPlugin
  • class StorageFactory

Special Cache Patterns:

  • namesapce Zend\Cache\Pattern
  • abstract AbstractPattern implements \Zend\Cache\Pattern
  • class CallbackCache extends AbstractPattern (Function and Callback calls)
  • class ClassCache extends AbstractPattern (only static method calls)
  • class ObjectCache extends AbstractPattern (only object method calls)
  • class OutputCache extends AbstractPattern
  • class PageCache extends AbstractPattern
  • class CaptureCache extends AbstractPattern
  • namespace \Zend\Cache
  • interface Pattern
  • class PatternFactory


  • namesapce Zend\Cache
  • class Manager


  • namesapce Zend\Cache\Profiler
  • class Profiler
  • class Profile


  • namesapce Zend\Cache\Exception
  • class RuntimeException extends \RuntimeException
  • class LogicException extends \LogicException
  • class InvalidArgumentException extends \InvalidArgumentException
  • class UnexpectedValueException extends \UnexpectedValueException
  • class ExtensionNotLoadedException extends \RuntimeException
  • class BadMethodCallException extends \BadMethodCallException
  • class ItemNotFoundException extends RuntimeException
  • class MissingKeyException extends RuntimeException
  • class MissingDependencyException extends RuntimeException

8. Use Cases

9. Class Skeletons

please look at



zf2 zf2 Delete
proposal proposal Delete
database database Delete
api api Delete
zend_cache zend_cache Delete
cache cache Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 27, 2010

    <p>I can't wait so see this enhancement ready, been struggling lately with "it's not possible to merge different frontens together" and had to give up...</p>

  2. Dec 05, 2010

    <p>Nice work on this. Seems it will be a pleasure to work with this component.</p>

  3. Mar 04, 2011

    <p>Seems like a small thing but the sharedmemory adapter should have a choice between shmop or shm (or do two adapter versions) - shmop works quite well on windows and the memory can be read with other tools (non-php tools even) very easily</p>

    1. Mar 10, 2011

      <p>I'll rename the adapter to SysvShm.</p>

      <p>But it's very difficult to write an adapter for shmop with good performance because it there is no native support to read/write variables by key and if you read/write + serialize/unserialize the complete memory segment it's much resource intensive.</p>

  4. Aug 10, 2011

    <p>What is the reason for set/addItem() to have <span style="color: rgb(153,51,0);">$value</span> as first argument and <span style="color: rgb(153,51,0);">$key</span> as second?<br />
    I understand that if key is ommited, _lastKey is used, yet it seems counterintuitive, because usually in all setters name/key goes as first argument. </p>

    1. Aug 10, 2011

      <p>My thoughts to implement it this way is based but this was noted also by Matthew and others.</p>

      <p>I need to update the proposal anyway because of more:</p>
      <ul class="alternate">
      <li>using Zend\EventManager for plug-in system</li>
      <li>switch the order of arguments to accept the key first</li>
      <li>What is the profiler?</li>
      <li>Where did the requirements come from?</li>

      <p>Today I'm currently testing how to implement all the plugins with an event based system (Zend\EventManager).<br />
      If I'm done having a good solution for this I'll update the proposal as soon as possible.<br />
      (see @ different branch: <a class="external-link" href=""></a>)</p>

      1. Aug 11, 2011

        <p>Sounds great. Thanks for the new branch link.</p>

      2. Sep 16, 2011


        <p>With the latest revision of cache_em on github current examples in this wiki article are not usable. Is there any working example for using a Filesystem adapter only for now?</p>

        <p>Tried to look at the tests but with no luck</p>

        <p>And when is it planned to publish a beta or alpha of this subpackage?</p>

        1. Sep 16, 2011

          <p>And yes, the arguments order it very confusing.</p>