It provides a basic infrastructure for building your own caching service, providing hooks for initialization and shutdown.
It provides convenience methods to start up the cache module, for example for the creation of a cache backend instance. There is no specific initialization done during startup, to allow the modules to do their own magic during startup (it is difficult to generalize such stuff).
The backend instance returned should be assigned by reference, to avoid handle duplication or the like.
The configuration array must include the configuration parameters driver and directory, as outlined in the midcom_services_cache_backend class documentation.
All backends will be collected in the $_backends array, indexed by their name.
Any duplicate instantiation will be intercepted, throwing a critical error.
stringThe name of the backend, must be unique throughout the system.
arrayThe configuration of the backend to create. It must contain the key 'driver', which indicates which backend to use.
\midcom_services_cache_backendA reference to the new backend.
You may, as it is required for the content cache, intercept requests. Terminate the requests with _midcom_stop_request() if you produce a complete output based on a previous request (page cache) of midcom_application::finish() if you produce regular output that might go into the content cache.
Note, that for example the page cache will not use this cleanup handler, as it produces a complete html page based on a previous request.
This will initialize the class configuration and call the corresponding event handler.
\GUIDThe GUID that has to be invalidated.
The default implementation will drop all entries from all registered cache backends using midcom_services_cache_backend::remove_all(). Override this function, if this behavior doesn't suit your needs.
This will fist call the corresponding event handler, and will close all registered backends afterwards.
They will be automatically shut down when the module shuts down. They are indexed by their name.