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_Manager Component Proposal

Proposed Component Name Zend_Cache_Manager
Developer Notes
Proposers Pádraic Brady
Revision 1.0 - 25 January 2009/28 July 2009 (wiki revision: 8)

Table of Contents

1. Overview

As a springboard to other proposals, Zend_Cache_Manager is intended to be a centralised Manager which is capable of creating, adapting, storing and otherwise tinkering with caches from one single location. It's other advantage from an ease of use view is that it offers a collection of lazy loaded preconfigured caches to play with before you even write a configuration file.

Since it's a springboard proposal, its intention is to simplify the development of dependent classes like helpers and plugins which will delegate some of their core functionality to the Manager and focus themselves on linking the Manager enabled features to the application layer they are targeting.

2. References

Source Code (In Development)
git repository

3. Component Requirements, Constraints, and Acceptance Criteria

  • MUST implement a fully funtional Cache Manager storing cache objects and configuration templates
  • MUST provide sufficient features to be delegated to by related helpers and plugins
  • WILL host other functionality after refacoring of helpers/plugins

4. Dependencies on Other Framework Components

  • Zend_Cache_*
  • Zend_Config
  • Zend_Exception

5. Theory of Operation

The Cache Manager is the core proposal in an effort to integrate simple to use caching into the MVC architecture of the Zend Framework through the use of helpers and plugins. Adding these elements individually would inevitably lead to coupling and code duplication, and the Cache Manager will offset these detrimental effects by offering a specific decoupled component dedicated to Cache Management which can be delegated to by other elements by proxy.

As a Cache Manager, the component has a simple set of facets:

1. Store all caches in a centralised location, but which are not statically accessible, to favour composition by external helpers/plugins.
2. Contain the creation logic for a collection of default caches usable across an application minimising setup time for developers.
3. Accept user configuration for all default caches to tailor the existing sensible options built into the Manager.
4. Allow the storage of Configuration Templates to support the lazy loading of requested caches based on these templates, and minimise setup code spreading at all application levels.
5. Adopt any duplicated roles common to future implemented plugins and helpers to minimise code duplication.

As you can see, the list is not that extensive. The Manager is a simple concept with simple use cases.

By storing caches internally, they can be accessed by helpers and plugins elsewhere and it likely will not rely on Zend_Registry since there's no real need to import another class dependency. Indeed, if you need a static instance - just store the Manager to the default registry.

The Manager will offer some very basic preconfigured caches to utilise in applications. These will follow the lowest common denominator approach, so they will favour filesystem storage over memory for example, since no PHP enviromental assumptions should be made.

The role of these caches is to ensure developers need not instantiate multiple small caches unnecessarily to support caching operations in helpers and plugins (which have predictable needs) - instead everything should work right away but allow developers to tweak configurations as needed between development, testing and production environments. These default caches will number approximately 3-4 and are all lazy loaded on demand assuming (where applicable) a file path to the cache directory of /cache (parallel to /applications). It is also assumed any sub-directories for these caches should be created by the Manager itself if not already existing.

The fourth role addresses the possibility of future refactoring to extract functionality from the proposed helpers/plugins which make Cache Manager access easier to minimise code duplication. It would require the completion of similar helpers/plugins before such refactoring oppotunities are identified (assuming they even materialise at all ). To demonstrate where Zend_Cache_Manager can see a simple use, please see the related proposal on static page caching where the Manager is used to write a simple Action Helper and preDispatch() task.

6. Milestones / Tasks

  • Milestone 1: Complete an initial version for comment
  • Milestone 2: Complete final feature list incorporating feedback
  • Milestone 3: Verify operation using Unit Tests
  • Milestone 4: Complete documentation

7. Class Index

  • Zend_Cache_Manager

8. Use Cases

UC-01: Storing a new cache
UC-02: Retrieving previously stored cache
UC-03: storing a cache configuration template for lazy loading
UC-04: Fetch a cache, which lazy loads instantiation from a previous configuration template
UC-05: Check if a cache (or configuration template) exists
UC-06: Ensure default caches cannot be overwritten once instantiated

9. Class Skeletons




proposal proposal Delete
proposals proposals Delete
cache cache Delete
zend_cache zend_cache Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 24, 2009

    <p>This thing is definatly missing in Zend_Cache currently! Its very hard to keep up with multiple caches and have them at a fine location somewhere.</p>

  2. Jan 25, 2009

    <p>Very cool idea. As Benjamin already said <ac:emoticon ac:name="smile" /> This is definatly missing functionality in Zend_Cache component.</p>

  3. Jan 25, 2009

    <p>Looks nice and flexible.</p>

    <p>There's always been the problem of managing multiple cache objects nicely. I ended up with a simple approach to the problem by giving the factory the ability to store configuration, but the solution isn't as flexible.
    <a class="external-link" href=""></a></p>

  4. Jan 26, 2009

    <p>The next few proposals will really emphasis the Cache Manager's purpose in centralising cache storage, configuration and creation. It makes adding helpers/plugins which require a cache simple by offering a single point to add custom caches, add lazy loaded caches (just store the configuration map) and offer default pre-configured (again, lazy loaded) caches to get started with minimal setup. First plugin I'm looking at is Zend_Controller_Action_Helper_Cache which will enable page caching to static HTML by default since it's a) the fastest possible cache for a page, and b) it requires no extraordinary setup or configuration, and c) it comes with a tagging system which makes it very simple to use. Without the Cache Manager, you'd be managing caches across every individual helper/plugin in the system - including any custom ones.</p>

  5. Jan 27, 2009

    <p>Loving the proposal as well, my only concern is that I also really like/need your other proposals and that your time is limited <ac:emoticon ac:name="wink" /></p>

  6. Jan 27, 2009

    <p>I'm fine at proposing, slow in implementing <ac:emoticon ac:name="wink" />. Seriously though it's a lack of time on my part due to work. I have more free time at the moment since I no longer do overtime (which was always a pain). That should be Zend_OAuth and Zend_Feed_Reader in the running for my attention in February to complete once and for all.</p>

  7. Jul 22, 2009

    <p>I think that there also should be a way to add global tags to the cache. Tags that need to be set on all caches, something like a namespace tag. Each application uses it's own global tags which then are used with all cache actions within that application. It still must be possible to set specific tags at the save and clean functions like it's currently possible. Only thing that changes is the implementation, where the global and specific tags are simply merged before use by the backends.</p>

    <p>A situation that I'm currently looking at is the following:</p>
    <p>A caching backend that is used/shared over multiple applications, like Zend Platform or memcached. Each application needs a global tag for all it's cache, so all cache for that specific application can be cleaned. And more specific cache can be cleaned by setting extra tags to cleanup.</p></blockquote>

    <p>The cache_id_prefix provides for seperating cache id's, but this cannot be used by a cleaning action of the cache. Using tags would be the best fit for this.</p>

    <p>I'm not sure what would be the best place to set this global cache tags, as close to the backends as possible would be best. Or maybe this is not the correct proposal to place this and the <a href="">Zend_Cache Refactoring</a> proposal would be a better fit for this.</p>

  8. Jul 28, 2009

    <p>Hi Patrick,</p>

    <p>I'm moving this proposal on to its review by Zend today, but don't let that discourage the train of thought above <ac:emoticon ac:name="wink" />. If you can come up with some use cases where this could (if not in the refactoring proposal) apply and be useful than fire them my way. You can catch me at (padraic dot brady at yahoo dot com) or padraicb on Twitter.</p>

  9. Jul 28, 2009

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Framework Acceptance</ac:parameter><ac:rich-text-body>
    <p>The Zend Framework Team is pleased to accept this proposal for immediate development in the Standard Incubator.</p>

    <p>We ask that you follow the requirements below when developing the component:</p>
    <li>Make sure the configuration-driven templating supports the TwoLevels cache</li>
    <li>Allow passing Zend_Config objects to setCacheTemplate()</li>
    <li>Where you have <strong>Config</strong> methods and variables, rename to <strong>Options</strong></li>

  10. Feb 22, 2011

    <p>Zend_Cache_Manager is released into the stable branch. Maybe we can archive this proposal <ac:emoticon ac:name="smile" /></p>