Caution: The documentation you are viewing is
for an older version of Zend Framework.
You can find the documentation of the current version at:
Available Resource Plugins - Zend_Application
Here you'll find API-like documentation about all resource plugins available by default in Zend_Application.
Zend_Application_Resource_Cachemanager may be utilised to configure a set of Zend_Cache option bundles for use when lazy loading caches using Zend_Cache_Manager
As the Cache Manager is a lazy loading mechanism, the options are translated to option templates used to instantiate a cache object on request.
Example #1 Sample Cachemanager resource configuration
Below is a sample INI file showing how Zend_Cache_Manager may be configured. The format is the Cachemanager resource prefix (resources.cachemanager) followed be the name to assign to an option cache template or bundle (e.g. resources.cachemanager.database) and finally followed by a typical Zend_Cache option.
Actually retrieving this cache from the Cache Manager is as simple as accessing an instance of the Manager (Zend_Cache_Manager) retrieved from Zend_Application_Resource_Cachemanager and calling Zend_Cache_Manager::getCache('database'). The example below is taken from a controller where the bootstrap class can be accessed as a Front Controller parameter (which is automatically assigned during bootstrapping). As you can see, the Cache Manager Resource implements a getCacheManager() method to retrieve the bootstrapped instance of Zend_Cache_Manager.
See Zend_Cache::factory() method to get a description of the default values you can assign when configuring a cache via a configuration file such as out example INI file above.
Zend_Application_Resource_Db will initialize a Zend_Db adapter based on the options passed to it. By default, it also sets the adapter as the default adapter for use with Zend_Db_Table. If you want to use mutliple databases simultaneously, you can use the Multidb Resource Plugin.
The following configuration keys are recognized:
adapter: Zend_Db adapter type.
params: associative array of configuration parameters to use when retrieving the adapter instance.
isDefaultTableAdapter: whether or not to establish this adapter as the default table adapter.
Example #2 Sample DB adapter resource configuration
Below is an example INI configuration that can be used to initialize the DB resource.
Note: Retrieving the Adapter instance
If you choose not to make the adapter instantiated with this resource the default table adapter, how do you retrieve the adapter instance?
As with any resource plugin, you can fetch the DB resource plugin from your bootstrap:Once you have the resource object, you can fetch the DB adapter using the getDbAdapter() method:
- $resource = $bootstrap->getPluginResource('db');
- $db = $resource->getDbAdapter();
Zend_Application_Resource_Dojo can be used to configure the Zend_Dojo viewhelpers.
Example #3 Sample Dojo resource configuration
Below is a sample INI file showing how Zend_Dojo can be enabled.
The Zend_Dojo resource plugin utilises the options for the Zend_Dojo_View_Helper_Dojo_Container::setOptions() to configure the viewhelpers. Please see the Zend_Dojo chapter for full descriptions and available options.
Probably the most common resource you will load with Zend_Application will be the Front Controller resource, which provides the ability to configure Zend_Controller_Front. This resource provides the ability to set arbitrary front controller parameters, specify plugins to initialize, and much more.
Once initialized, the resource assigns the $frontController property of the bootstrap to the Zend_Controller_Front instance.
Available configuration keys include the following, and are case insensitive:
controllerDirectory: either a string value specifying a single controller directory, or an array of module to controller directory pairs.
moduleControllerDirectoryName: a string value indicating the subdirectory under a module that contains controllers.
moduleDirectory: directory under which modules may be found.
defaultControllerName: base name of the default controller (normally "index").
defaultAction: base name of the default action (normally "index").
defaultModule: base name of the default module (normally "default").
baseUrl: explicit base URL to the application (normally auto-detected).
plugins: array of front controller plugin class names. The resource will instantiate each class (with no constructor arguments) and then register the instance with the front controller. If you want to register a plugin with a particular stack index, you need to provide an array with two keys class and stackIndex.
params: array of key to value pairs to register with the front controller.
returnresponse: whether or not to return the response object after dispatching the front controller. Value should be a boolean; by default, this is disabled.
If an unrecognized key is provided, it is registered as a front controller parameter by passing it to setParam().
Example #4 Sample Front Controller resource configuration
Below is a sample INI snippet showing how to configure the front controller resource.
Example #5 Retrieving the Front Controller in your bootstrap
Once your Front Controller resource has been initialized, you can fetch the Front Controller instance via the $frontController property of your bootstrap.
Zend_Application_Resource_Layout can be used to configure Zend_Layout. Configuration options are per the Zend_Layout options.
Example #6 Sample Layout configuration
Below is a sample INI snippet showing how to configure the layout resource.
Zend_Application_Resource_Locale can be used to set an application-wide locale which is then used in all classes and components which work with localization or internationalization.
There are basically three usecases for the Locale Resource Plugin. Each of them should be used depending on the applications need.
Without specifying any options for Zend_Application_Resource_Locale, Zend_Locale will detect the locale, which your application will use, automatically.
This detection works because your client sends the wished language within his HTTP request. Normally the clients browser sends the languages he wants to see, and Zend_Locale uses this information for detection.
But there are 2 problems with this approach:
The browser could be setup to send no language
The user could have manually set a locale which does not exist
In both cases Zend_Locale will fallback to other mechanism to detect the locale:
When a locale has been set which does not exist, Zend_Locale tries to downgrade this string.
When, for example, en_ZZ is set it will automatically be degraded to en. In this case en will be used as locale for your application.
When the locale could also not be detected by downgrading, the locale of your environment (web server) will be used. Most available environments from Web Hosters use en as locale.
When the systems locale could not be detected Zend_Locale will use it's default locale, which is set to en per default.
For more informations about locale detection take a look into this chapter on Zend_Locale's automatic detection.
The above autodetection could lead to problems when the locale could not be detected and you want to have another default locale than en. To prevent this, Zend_Application_Resource_Locale allows you to set a own locale which will be used in the case that the locale could not be detected.
Example #7 Autodetect locale and setting a fallback
The following snippet shows how to set a own default locale which will be used when the client does not send a locale himself.
Sometimes it is useful to define a single locale which has to be used. This can be done by using the force option.
In this case this single locale will be used and the automatic detection is turned off.
Example #8 Defining a single locale to use
The following snippet shows how to set a single locale for your entire application.
Zend_Application_Resource_Log to instantiate a Zend_Log instance with an arbitrary number of log writers. Configuration will be passed to the Zend_Log::factory() method, allowing you to specify combinations of log writers and filters. The log instance may then be retrieved from the bootstrap later in order to log events.
Example #9 Sample Log Resource Configuration
Below is a sample INI snippet showing how to configure the log resource.
For more information on available options, please review the Zend_Log::factory() documentation.
Zend_Application_Resource_Mail can be used to instantiate a transport for Zend_Mail or set the default name and address, as well as the default replyto- name and address.
When instantiating a transport, it's registered automatically to Zend_Mail. Though, by setting the transport.register directive to FALSE, this behaviour does no more occur.
Example #10 Sample Mail Resource Configuration
Below is a sample INI snippet showing how to configure the mail resource plugin.
Zend_Application_Resource_Modules is used to initialize your application modules. If your module has a Bootstrap.php file in its root, and it contains a class named Module_Bootstrap (where "Module" is the module name), then it will use that class to bootstrap the module.
By default, an instance of Zend_Application_Module_Autoloader will be created for the module, using the module name and directory to initialize it.
Since the Modules resource does not take any arguments by default, in order to enable it via configuration, you need to create it as an empty array. In INI style configuration, this looks like:
In XML style configuration, this looks like:
Using a standard PHP array, simply create it as an empty array:
Note: Front Controller Resource Dependency
The Modules resource has a dependency on the Front Controller resource. You can, of course, provide your own replacement for that resource via a custom Front Controller resource class or a class initializer method -- so long as the resource plugin class ends in "Frontcontroller" or the initializer method is named "_initFrontController" (case insensitive).
Example #11 Configuring Modules
You can specify module-specific configuration using the module name as a prefix or sub-section in your configuration file.
For example, let's assume that your application has a "news" module. The following are INI and XML examples showing configuration of resources in that module.
Example #12 Retrieving a specific module bootstrap
On occasion, you may need to retrieve the bootstrap object for a specific module -- perhaps to run discrete bootstrap methods, or to fetch the autoloader in order to configure it. This can be done using the Modules resource's getExecutedBootstraps() method.
Zend_Application_Resource_Multidb is used to initialize multiple Database connections. You can use the same options as you can with the Db Resource Plugin. However, for specifying a default connection, you can also use the 'default' directive.
Example #13 Setting up multiple Db Connections
Below is an example INI configuration that can be used to initialize two Db Connections.
Example #14 Retrieving a specific database adapter
When using this resource plugin you usually will want to retrieve a specific database. This can be done by using the resource's getDb(). The method getDb() returns an instance of a class that extends Zend_Db_Adapter_Abstract. If you have not set a default database, an exception will be thrown when this method is called without specifying a parameter.
Example #15 Retrieving the default database adapter
Additionally, you can retrieve the default database adapter by using the method getDefaultDb(). If you have not set a default adapter, the first configured db adapter will be returned. Unless you specify FALSE as first parameter, then NULL will be returned when no default database adapter was set.
Below is an example that assumes the Multidb resource plugin has been configured with the INI sample above:
Zend_Application_Resource_Router can be used to configure the router as it is registered with the Front Controller. Configuration options are per the Zend_Controller_Router_Route options.
Example #17 Sample Router Resource configuration
Below is a sample INI snippet showing how to configure the router resource.
For more information on the Chain Name Separator, please see its section.
Zend_Application_Resource_Session allows you to configure Zend_Session as well as optionally initialize a session SaveHandler.
To set a session save handler, simply pass the saveHandler (case insensitive) option key to the resource. The value of this option may be one of the following:
String : A string indicating a class implementing Zend_Session_SaveHandler_Interface that should be instantiated.
Array : An array with the keys "class" and, optionally, "options", indicating a class implementing Zend_Session_SaveHandler_Interface that should be instantiated and an array of options to provide to its constructor.
Zend_Session_SaveHandler_Interface: an object implementing this interface.
Any other option keys passed will be passed to Zend_Session::setOptions() to configure Zend_Session.
Example #18 Sample Session resource configuration
Below is a sample INI snippet showing how to configure the session resource. It sets several Zend_Session options, as well as configures a Zend_Session_SaveHandler_DbTable instance.
Note: Bootstrap your database first!
If you are configuring the Zend_Session_SaveHandler_DbTable session save handler, you must first configure your database connection for it to work. Do this by either using the Db resource -- and make sure the "resources.db" key comes prior to the "resources.session" key -- or by writing your own resource that initializes the database, and specifically sets the default Zend_Db_Table adapter.
Zend_Application_Resource_View can be used to configure a Zend_View instance. Configuration options are per the Zend_View options.
Once done configuring the view instance, it creates an instance of Zend_Controller_Action_Helper_ViewRenderer and registers the ViewRenderer with Zend_Controller_Action_HelperBroker -- from which you may retrieve it later.
Example #19 Sample View resource configuration
Below is a sample INI snippet showing how to configure the view resource.