Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

<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 http://framework.zend.com/wiki/display/ZFDEV/Zend_Cache_Manager
Proposers Pádraic Brady
Revision 0.95 - 25 January 2009 (wiki revision: 3)

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, it's 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 linked the Manager enabled features to the application layer they are targeting.

2. References

Source Code (In Development)
[git:http://github.com/padraic/zfcache]

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 Framework Classes

  • 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. Adopt any duplicated roles common to future implemented plugins and helpers to minimise code duplication.

As you can see, the list is not extensive.

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.

The Manager will offer some 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 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 proposed helpers/plugins 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 ).

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

Class skeletons will be published here as development progresses.

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.