compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (11)

View Page History

0.95 1.0 - 25 January 2009/28 July 2009

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 linking the Manager enabled features to the application layer they are targeting.

*Zend Framework Classes*
* Zend_Cache_*
* Zend_Config
* Zend_Exception
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.
45. 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.