Default Services

The default and recommended way to write zend-mvc applications uses a set of services defined in the Zend\Mvc\Service namespace. This chapter details what each of those services are, the classes they represent, and the configuration options available.

Many of the services are provided by other components, and the factories and abstract factories themselves are defined in the individual components. We will cover those factories in this chapter, however, as usage is generally the same between each.

Theory of Operation

To allow easy configuration of all the different parts of the MVC system, a somewhat complex set of services and their factories has been created. We'll try to give a simplified explanation of the process.

When a Zend\Mvc\Application is created, a Zend\ServiceManager\ServiceManager object is created and configured via Zend\Mvc\Service\ServiceManagerConfig. The ServiceManagerConfig gets the configuration from config/application.config.php (or some other application configuration you passed to the Application when creating it). From all the service and factories provided in the Zend\Mvc\Service namespace, ServiceManagerConfig is responsible of configuring only three: SharedEventManager, EventManager, and ModuleManager.

After this, the Application fetches the ModuleManager. At this point, the ModuleManager further configures the ServiceManager with services and factories provided in Zend\Mvc\Service\ServiceListenerFactory. This approach allows us to keep the main application configuration concise, and to give the developer the power to configure different parts of the MVC system from within the modules, overriding any default configuration in these MVC services.

ServiceManager

As a quick review, the following service types may be configured:

The application service manager is referenced directly during bootstrapping, and has the following services configured out of the box.

Invokable services

Factories

Abstract factories

Aliases

Initializers

Abstract Factories

As noted in the previous section, Zend Framework provides a number of abstract service factories by default. Each is noted below, along with sample configuration.

In each instance, the abstract factory looks for a top-level configuration key, consisting of key/value pairs where the key is the service name, and the value is the configuration to use to create the given service.

Zend\Cache\Service\StorageCacheAbstractServiceFactory

This abstract factory is opt-in, but registered by default in the skeleton application. It uses the top-level configuration key "caches".

return [
    'caches' => [
        'Cache\Transient' => [
            'adapter' => 'redis',
            'ttl'     => 60,
            'plugins' => [
                'exception_handler' => [
                    'throw_exceptions' => false,
                ],
            ],
        ],
        'Cache\Persistence' => [
            'adapter' => 'filesystem',
            'ttl'     => 86400,
        ],
    ],
];

See the cache documentation for more configuration options.

Zend\Db\Adapter\AdapterAbstractServiceFactory

This abstract factory is opt-in. It uses the top-level configuration key "db", with a subkey "adapters".

return [
    'db' => ['adapters' => [
        'Db\ReadOnly' => [
            'driver'   => 'Pdo_Sqlite',
            'database' => 'data/db/users.db',
        ],
        'Db\Writeable' => [
            'driver'   => 'Mysqli',
            'database' => 'users',
            'username' => 'developer',
            'password' => 'developer_password',
        ],
    ]],
];

See the DB adapter documentation for more configuration options.

Zend\Form\FormAbstractServiceFactory

This abstract factory is registered by default. It uses the top-level configuration key "forms". It makes use of the FilterManager, FormElementManager, HydratorManager, InputFilterManager, and ValidatorManager plugin managers in order to allow instantiation and creation of form objects and all related objects in the form hierarchy.

return [
    'forms' => [
        'Form\Foo' => [
            'hydrator' => 'ObjectProperty',
            'type'     => 'Zend\Form\Form',
            'elements' => [
                [
                    'spec' => [
                        'type' => 'Zend\Form\Element\Email',
                        'name' => 'email',
                        'options' => [
                            'label' => 'Your email address',
                        ],
                    ],
                ],
            ],
        ],
    ],
];

Form configuration follows the same configuration you would use with a form factory; the primary difference is that all plugin managers have already been injected for you, allowing you the possibility of custom objects or substitutions.

See the form factory documentation for more configuration options.

Zend\Log\LoggerAbstractServiceFactory

This abstract factory is opt-in, but registered by default in the skeleton application. It uses the top-level configuration key "log".

return [
    'log' => [
        'Log\App' => [
            'writers' => [
                [
                    'name' => 'stream',
                    'priority' => 1000,
                    'options' => [
                        'stream' => 'data/logs/app.log',
                    ],
                ],
            ],
        ],
    ],
];

See the log documentation for more configuration options.

Plugin Managers

The following plugin managers are configured by default:

As noted in the previous section, all plugin managers share the same configuration and service types as the standard service manager; they are simply scoped, and only allow instances of certain types to be created or registered. Default types available are listed in the documentation for each component.

ViewManager

The View layer within zend-mvc consists of a large number of collaborators and event listeners. As such, Zend\Mvc\View\ViewManager was created to handle creation of the various objects, as well as wiring them together and establishing event listeners.

The ViewManager itself is an event listener on the bootstrap event. It retrieves the ServiceManager from the Application object, as well as its composed EventManager.

Configuration for all members of the ViewManager fall under the view_manager configuration key, and expect values as noted below. The following services are created and managed by the ViewManager:

The ViewManager also creates several other listeners, but does not expose them as services; these include Zend\Mvc\View\CreateViewModelListener, Zend\Mvc\View\InjectTemplateListener, and Zend\Mvc\View\InjectViewModelListener. These, along with RouteNotFoundStrategy, ExceptionStrategy, and DefaultRenderingStrategy are attached as listeners either to the application EventManager instance or the SharedEventManager instance.

Finally, if you have a strategies key in your configuration, the ViewManager will loop over these and attach them in order to the View service as listeners, at a priority of 100 (allowing them to execute before the DefaultRenderingStrategy).

Application Configuration Options

The following options may be used to provide initial configuration for the ServiceManager, ModuleManager, and Application instances, allowing them to then find and aggregate the configuration used for the Config service, which is intended for configuring all other objects in the system. These configuration directives go to the config/application.config.php file.

<?php
return [
    // This should be an array of module namespaces used in the application.
    'modules' => [
    ],

    // These are various options for the listeners attached to the ModuleManager
    'module_listener_options' => [
        // This should be an array of paths in which modules reside.
        // If a string key is provided, the listener will consider that a module
        // namespace, the value of that key the specific path to that module's
        // Module class.
        'module_paths' => [
        ],

        // An array of paths from which to glob configuration files after
        // modules are loaded. These effectively override configuration
        // provided by modules themselves. Paths may use GLOB_BRACE notation.
        'config_glob_paths' => [
        ],

        // Whether or not to enable a configuration cache.
        // If enabled, the merged configuration will be cached and used in
        // subsequent requests.
        'config_cache_enabled' => $booleanValue,

        // The key used to create the configuration cache file name.
        'config_cache_key' => $stringKey,

        // Whether or not to enable a module class map cache.
        // If enabled, creates a module class map cache which will be used
        // by in future requests, to reduce the autoloading process.
        'module_map_cache_enabled' => $booleanValue,

        // The key used to create the class map cache file name.
        'module_map_cache_key' => $stringKey,

        // The path in which to cache merged configuration.
        'cache_dir' => $stringPath,

        // Whether or not to enable modules dependency checking.
        // Enabled by default, prevents usage of modules that depend on other modules
        // that weren't loaded.
        'check_dependencies' => $booleanValue,
    ],

    // Used to create an own service manager. May contain one or more child arrays.
    'service_listener_options' => [
       [
         'service_manager' => $stringServiceManagerName,
         'config_key'      => $stringConfigKey,
         'interface'       => $stringOptionalInterface,
         'method'          => $stringRequiredMethodName,
       ],
    ]

    // Initial configuration with which to seed the ServiceManager.
    // Should be compatible with Zend\ServiceManager\Config.
    'service_manager' => [
    ],
];

For an example, see the ZendSkeletonApplication configuration file.

Default Configuration Options

The following options are available when using the default services configured by the ServiceManagerConfig and ViewManager.

These configuration directives can go to the config/autoload/{{,*.}global,{,*.}local}.php files, or in the module/<module name>/config/module.config.php configuration files. The merging of these configuration files is done by the ModuleManager. It first merges each module's module.config.php file, and then the files in config/autoload (first the *.global.php and then the *.local.php files). The order of the merge is relevant so you can override a module's configuration with your application configuration. If you have both a config/autoload/my.global.config.php and config/autoload/my.local.config.php, the local configuration file overrides the global configuration.

Do not commit local configuration

Local configuration files are intended to keep sensitive information, such as database credentials, and as such, it is highly recommended to keep these local configuration files out of your VCS. The ZendSkeletonApplication's config/autoload/.gitignore file ignores *.local.php files by default.

<?php
return [
    // The following are used to configure controller loader
    // Should be compatible with Zend\ServiceManager\Config.
    'controllers' => [
        // Map of controller "name" to class
        // This should be used if you do not need to inject any dependencies
        // in your controller
        'invokables' => [
        ],

        // Map of controller "name" to factory for creating controller instance
        // You may provide either the class name of a factory, or a PHP callback.
        'factories' => [
        ],
    ],

    // The following are used to configure controller plugin loader
    // Should be compatible with Zend\ServiceManager\Config.
    'controller_plugins' => [
    ],

    // The following are used to configure view helper manager
    // Should be compatible with Zend\ServiceManager\Config.
    'view_helpers' => [
    ],

    // The following is used to configure a Zend\Di\Di instance.
    // The array should be in a format that Zend\Di\Config can understand.
    'di' => [
    ],

    // Configuration for the Router service
    // Can contain any router configuration, but typically will always define
    // the routes for the application. See the router documentation for details
    // on route configuration.
    'router' => [
        'routes' => [
        ],
    ],

    // ViewManager configuration
    'view_manager' => [
        // Base URL path to the application
        'base_path' => $stringBasePath,

        // Doctype with which to seed the Doctype helper
        'doctype' => $doctypeHelperConstantString, // e.g. HTML5, XHTML1

        // TemplateMapResolver configuration
        // template/path pairs
        'template_map' => [
        ],

        // TemplatePathStack configuration
        // module/view script path pairs
        'template_path_stack' => [
        ],
        // Default suffix to use when resolving template scripts, if none, 'phtml' is used
        'default_template_suffix' => $templateSuffix, // e.g. 'php'

        // Controller namespace to template map
        'controller_map' => [
        ],

        // Layout template name
        'layout' => $layoutTemplateName, // e.g. 'layout/layout'

        // ExceptionStrategy configuration
        'display_exceptions' => $bool, // display exceptions in template
        'exception_template' => $stringTemplateName, // e.g. 'error'

        // RouteNotFoundStrategy configuration
        'display_not_found_reason' => $bool, // display 404 reason in template
        'not_found_template' => $stringTemplateName, // e.g. '404'

        // Additional strategies to attach
        // These should be class names or service names of View strategy classes
        // that act as ListenerAggregates. They will be attached at priority 100,
        // in the order registered.
        'strategies' => [
            'ViewJsonStrategy', // register JSON renderer strategy
            'ViewFeedStrategy', // register Feed renderer strategy
        ],
    ],
];

For an example, see the Application module configuration file in the ZendSkeletonApplication.