Here you'll find API-like documentation about all resource plugins
available by default in
Zend_Application_Resource_Cachemanager may be
utilised to configure a set of
bundles for use when lazy loading caches using
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
resources.cachemanager.database.frontend.name = Core resources.cachemanager.database.frontend.customFrontendNaming = false resources.cachemanager.database.frontend.options.lifetime = 7200 resources.cachemanager.database.frontend.options.automatic_serialization = true resources.cachemanager.database.backend.name = File resources.cachemanager.database.backend.customBackendNaming = false resources.cachemanager.database.backend.options.cache_dir = "/path/to/cache" resources.cachemanager.database.frontendBackendAutoload = false
Actually retrieving this cache from the Cache Manager is as simple as
accessing an instance of the Manager (
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
$manager = $this->getFrontController() ->getParam('bootstrap') ->getPluginResource('cachemanager') ->getCacheManager(); $dbCache = $manager->getCache('database');
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
The following configuration keys are recognized:
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.
defaultMetadataCache: the name of the
cache template or an instance of
Zend_Cache_Core to use as
metadata cache for
Example #2 Sample DB adapter resource configuration
Below is an example INI configuration that can be used to initialize the DB resource.
[production] resources.db.adapter = "pdo_mysql" resources.db.params.host = "localhost" resources.db.params.username = "webuser" resources.db.params.password = "XXXXXXX" resources.db.params.dbname = "test" resources.db.isDefaultTableAdapter = true ; Optionally you can also the cache template to use for metadata caching: resources.db.defaultMetadataCache = "database"
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:$resource = $bootstrap->getPluginResource('db');
Once you have the resource object, you can fetch the DB adapter using the getDbAdapter() method:$db = $resource->getDbAdapter();
Zend_Application_Resource_Dojo can be used
to configure the
Example #3 Sample Dojo resource configuration
Below is a sample INI file showing how
Zend_Dojo can be enabled.
Zend_Dojo resource plugin utilises the options for the
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
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.
[production] resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers" resources.frontController.moduleControllerDirectoryName = "actions" resources.frontController.moduleDirectory = APPLICATION_PATH "/modules" resources.frontController.defaultControllerName = "site" resources.frontController.defaultAction = "home" resources.frontController.defaultModule = "static" resources.frontController.baseUrl = "/subdir" resources.frontController.plugins.foo = "My_Plugin_Foo" resources.frontController.plugins.bar = "My_Plugin_Bar" resources.frontController.plugins.baz.class = "My_Plugin_Baz" resources.frontController.plugins.baz.stackIndex = 123 resources.frontController.returnresponse = 1 resources.frontController.env = APPLICATION_ENV ; The following proxies to: ; Zend_Controller_Action_HelperBroker::addPath('Helper_Path', $helperPrefix); resources.frontController.actionHelperPaths.HELPER_Prefix = "My/Helper/Path"
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.
$bootstrap->bootstrap('frontController'); $front = $bootstrap->frontController;
Zend_Application_Resource_Layout can be used to
Zend_Layout. Configuration options are
Example #6 Sample Layout configuration
Below is a sample INI snippet showing how to configure the layout resource.
resources.layout.layout = "NameOfDefaultLayout" resources.layout.layoutPath = "/path/to/layouts"
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. By default the locale is
saved in a
Zend_Registry entry with key
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_Locale will detect the locale, which your application will
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
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
will use it's default locale, which is set to en per
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.
; Try to determine automatically first, ; if unsuccessful, use nl_NL as fallback. resources.locale.default = "nl_NL"
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.
; No matter what, the nl_NL locale will be used. resources.locale.default = "nl_NL" resources.locale.force = true
When you have set no cache,
Zend_Locale will set itself a cache
with the file backend by default. But if you want to choose the backend or others
options, you can use the name of a cache template or an instance of
For more informations look into Speed up Zend_Locale and its subclasses.
Example #9 Defining a cache template to use
; Optionally you can also the cache template to use for caching: resources.locale.cache = "locale"
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 #10 Sample Log Resource Configuration
Below is a sample INI snippet showing how to configure the log resource.
resources.log.stream.writerName = "Stream" resources.log.stream.writerParams.stream = APPLICATION_PATH "/../data/logs/application.log" resources.log.stream.writerParams.mode = "a" resources.log.stream.filterName = "Priority" resources.log.stream.filterParams.priority = 4
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 #11 Sample Mail Resource Configuration
Below is a sample INI snippet showing how to configure the mail resource plugin.
resources.mail.transport.type = smtp resources.mail.transport.host = "smtp.example.com" resources.mail.transport.auth = login resources.mail.transport.username = myUsername resources.mail.transport.password = myPassword resources.mail.transport.register = true ; True by default resources.mail.defaultFrom.email = email@example.com resources.mail.defaultFrom.name = "John Doe" resources.mail.defaultReplyTo.email = Jane@example.com resources.mail.defaultReplyTo.name = "Jane Doe"
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
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:
$options = array( 'resources' => array( 'modules' => 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 #12 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.
[production] news.resources.db.adapter = "pdo_mysql" news.resources.db.params.host = "localhost" news.resources.db.params.username = "webuser" news.resources.db.params.password = "XXXXXXX" news.resources.db.params.dbname = "news"
pdo_mysql localhost webuser XXXXXXX news true
Example #13 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.
$resource = $bootstrap->getPluginResource('modules'); $moduleBootstraps = $resource->getExecutedBootstraps(); $newsBootstrap = $moduleBootstraps['news'];
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 #14 Setting up multiple Db Connections
Below is an example INI configuration that can be used to initialize two Db Connections.
[production] resources.multidb.db1.adapter = "pdo_mysql" resources.multidb.db1.host = "localhost" resources.multidb.db1.username = "webuser" resources.multidb.db1.password = "XXXX" resources.multidb.db1.dbname = "db1" resources.multidb.db2.adapter = "pdo_pgsql" resources.multidb.db2.host = "example.com" resources.multidb.db2.username = "dba" resources.multidb.db2.password = "notthatpublic" resources.multidb.db2.dbname = "db2" resources.multidb.db2.default = true
Example #15 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
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.
$resource = $bootstrap->getPluginResource('multidb'); $db1 = $resource->getDb('db1'); $db2 = $resource->getDb('db2'); $defaultDb = $resource->getDb();
Example #16 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:
$resource = $bootstrap->getPluginResource('multidb'); $db2 = $resource->getDefaultDb(); // Same config, but now without a default db: $db1 = $resource->getDefaultDb(); $null = $resource->getDefaultDb(false); // null
Zend_Application_Resource_Navigation can be used to configure
Zend_Navigation instance. Configuration options are per the
Once done configuring the navigation instance, it assigns the instance to
Zend_View_Helper_Navigation by default
-- from which you may retrieve it later.
Example #17 Sample Navigation resource configuration
Below is a sample INI snippet showing how to configure the navigation resource.
resources.navigation.pages.page1.label = "Label of the first page" resources.navigation.pages.page1.route = "Route that belongs to the first page" ; Page 2 is a subpage of page 1 resources.navigation.pages.page1.pages.page2.type = "Zend_Navigation_Page_Uri" resources.navigation.pages.page1.pages.page2.label = "Label of the second page" resources.navigation.pages.page1.pages.page2.uri = "/url/to/page/2"
Zend_Application_Resource_Router can be used to
configure the router as it is registered with the Front Controller.
Configuration options are per the
Example #18 Sample Router Resource configuration
Below is a sample INI snippet showing how to configure the router resource.
resources.router.routes.route_id.route = "/login" resources.router.routes.route_id.defaults.module = "user" resources.router.routes.route_id.defaults.controller = "login" resources.router.routes.route_id.defaults.action = "index" ; Optionally you can also set a Chain Name Separator: resources.router.chainNameSeparator = "_"
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
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
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
Example #19 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
resources.session.save_path = APPLICATION_PATH "/../data/session" resources.session.use_only_cookies = true resources.session.remember_me_seconds = 864000 resources.session.saveHandler.class = "Zend_Session_SaveHandler_DbTable" resources.session.saveHandler.options.name = "session" resources.session.saveHandler.options.primary = "session_id" resources.session.saveHandler.options.primary = "save_path" resources.session.saveHandler.options.primary = "name" resources.session.saveHandler.options.primaryAssignment = "sessionId" resources.session.saveHandler.options.primaryAssignment = "sessionSavePath" resources.session.saveHandler.options.primaryAssignment = "sessionName" resources.session.saveHandler.options.modifiedColumn = "modified" resources.session.saveHandler.options.dataColumn = "session_data" resources.session.saveHandler.options.lifetimeColumn = "lifetime"
Note: Bootstrap your database first!
If you are configuring the
Zend_Session_SaveHandler_DbTablesession 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_Application_Resource_Translate will initialize a
Zend_Translate adapter based on the options passed to it.
The following configuration keys are recognized:
adapter type. The default adapter is array if not specified.
data : path to translation.
locale : defining the locale to be used
in translation. By default, the locale can be detected automatically or forcing
Zend_Locale instance store in
Zend_Registry with a single locale.
options : the options are different for each adapter. See the section Options for adapters for more details.
registry : the custom key to store the
Zend_Translate instance in the registry. By default, the
key is Zend_Translate.
cache : the name of the cache template
or an instance of
Zend_Cache_Core to use as cache for
Zend_Translate_Adapter. The goal is to accelerate the
loading specialy for the XML based files.
Example #20 Sample translate adapter resource configuration
Below is an example INI configuration that can be used to initialize the translate resource.
resources.translate.adapter = tmx resources.translate.content = APPLICATION_PATH "/../data/locales" resources.translate.scan = Zend_Translate::LOCALE_DIRECTORY ; Optionally you can also the cache template to use for caching: resources.translate.cache = "languages"
This resource provides the ability to configure and instantiate Zend_Http_UserAgent for use within your application.
Zend_Http_UserAgent, including usage of the application
resource, is covered in the UserAgent quick start. Below is a
quick summary of typical options you might provide.
resources.useragent.wurflapi.wurfl_api_version = "1.1" resources.useragent.wurflapi.wurfl_lib_dir = APPLICATION_PATH "/../library/Wurfl/1.1" resources.useragent.wurflapi.wurfl_config_file = APPLICATION_PATH "/../library/Wurfl/1.1/resources/wurfl-config.php"
Please see the UserAgent options section for details on available options.
Called by the bootstrap object to initialize the resource. Calls the
getUserAgent() method first (and returns the instance
returned by that method); then, if the "view" resource is available, retrieves
it and injects the
UserAgent instance into the
UserAgent view helper.
Zend_Http_UserAgent instance, using the
configuration options provided in the application configuration.
Zend_Application_Resource_View can be used to configure
Zend_View instance. Configuration options are per the
Once done configuring the view instance, it creates an instance of
Zend_Controller_Action_Helper_ViewRenderer and registers
the ViewRenderer with
-- from which you may retrieve it later.
Example #21 Sample View resource configuration
Below is a sample INI snippet showing how to configure the view resource.
resources.view.encoding = "UTF-8" resources.view.basePath = APPLICATION_PATH "/views/"
If you want to obtain more information about values, see Doctype Helper .
Example #22 Sample doctype configuration
The following snippet shows how to set a doctype.
resources.view.doctype = "HTML5"
If you want to obtain more information about values, see HeadMeta Helper .
Example #23 Sample content type and encoding configuration
The following snippet shows how to set a meta Content-Type.
resources.view.contentType = "text/html; charset=UTF-8"
Example #24 Sample encoding configuration for a HTML5 document
The following snippet shows how to set a meta charset in HTML5-style.
resources.view.doctype = "HTML5" resources.view.charset = "UTF-8"