diff --git a/doc/book/zend.mvc.controllers.md b/doc/book/zend.mvc.controllers.md index 8e80a3f0d..9f2a5dca2 100644 --- a/doc/book/zend.mvc.controllers.md +++ b/doc/book/zend.mvc.controllers.md @@ -104,10 +104,10 @@ often difficult to achieve cleanly in abstract, general systems. Within your controllers, you'll often find yourself repeating tasks from one controller to another. Some common examples: -- Generating URLs -- Redirecting -- Setting and retrieving flash messages (self-expiring session messages) -- Invoking and dispatching additional controllers +* Generating URLs +* Redirecting +* Setting and retrieving flash messages (self-expiring session messages) +* Invoking and dispatching additional controllers To facilitate these actions while also making them available to alternate controller implementations, we've created a `PluginManager` implementation for the controller layer, @@ -149,13 +149,13 @@ As such, we've developed two abstract, base controllers you can extend to get st The first is `Zend\Mvc\Controller\AbstractActionController`. This controller implements each of the above interfaces, and uses the following assumptions: -- An "action" parameter is expected in the `RouteMatch` object composed in the attached `MvcEvent`. +* An "action" parameter is expected in the `RouteMatch` object composed in the attached `MvcEvent`. If none is found, a `notFoundAction()` is invoked. -- The "action" parameter is converted to a camelCased format and appended with the word "Action" to +* The "action" parameter is converted to a camelCased format and appended with the word "Action" to create a method name. As examples: "foo" maps to "fooAction", "foo-bar" or "foo.bar" or "foo\_bar" to "fooBarAction". The controller then checks to see if that method exists. If not, the `notFoundAction()` method is invoked; otherwise, the discovered method is called. -- The results of executing the given action method are injected into the `MvcEvent`'s "result" +* The results of executing the given action method are injected into the `MvcEvent`'s "result" property (via `setResult()`, and accessible via `getResult()`). Essentially, a route mapping to an `AbstractActionController` needs to return both "controller" and @@ -186,16 +186,16 @@ class BarController extends AbstractActionController `AbstractActionController` implements each of the following interfaces: -- `Zend\Stdlib\DispatchableInterface` -- `Zend\Mvc\InjectApplicationEventInterface` -- `Zend\ServiceManager\ServiceLocatorAwareInterface` -- `Zend\EventManager\EventManagerAwareInterface` +* `Zend\Stdlib\DispatchableInterface` +* `Zend\Mvc\InjectApplicationEventInterface` +* `Zend\ServiceManager\ServiceLocatorAwareInterface` +* `Zend\EventManager\EventManagerAwareInterface` The composed `EventManager` will be configured to listen on the following contexts: -- `Zend\Stdlib\DispatchableInterface` -- `Zend\Mvc\Controller\AbstractActionController` -- `Zend\Mvc\Controller\AbstractController` +* `Zend\Stdlib\DispatchableInterface` +* `Zend\Mvc\Controller\AbstractActionController` +* `Zend\Mvc\Controller\AbstractController` Additionally, if you extend the class, it will listen on the extending class's name. @@ -205,18 +205,18 @@ The second abstract controller ZF2 provides is `Zend\Mvc\Controller\AbstractRest controller provides a native RESTful implementation that simply maps HTTP request methods to controller methods, using the following matrix: -- **GET** maps to either `get()` or `getList()`, depending on whether or not an "id" parameter is +* **GET** maps to either `get()` or `getList()`, depending on whether or not an "id" parameter is found in the route matches. If one is, it is passed as an argument to `get()`; if not, `getList()` is invoked. In the former case, you should provide a representation of the given entity with that identification; in the latter, you should provide a list of entities. -- **POST** maps to `create()`. That method expects a `$data` argument, usually the `$_POST` +* **POST** maps to `create()`. That method expects a `$data` argument, usually the `$_POST` superglobal array. The data should be used to create a new entity, and the response should typically be an HTTP 201 response with the Location header indicating the URI of the newly created entity and the response body providing the representation. -- **PUT** maps to `update()`, and requires that an "id" parameter exists in the route matches; that +* **PUT** maps to `update()`, and requires that an "id" parameter exists in the route matches; that value is passed as an argument to the method. It should attempt to update the given entity, and, if successful, return either a 200 or 202 response status, as well as the representation of the entity. -- **DELETE** maps to `delete()`, and requires that an "id" parameter exists in the route matches; +* **DELETE** maps to `delete()`, and requires that an "id" parameter exists in the route matches; that value is passed as an argument to the method. It should attempt to delete the given entity, and, if successful, return either a 200 or 204 response status. @@ -229,15 +229,15 @@ used to submit to the various RESTful methods, or to add RPC methods to your RES `AbstractRestfulController` implements each of the following interfaces: -- `Zend\Stdlib\DispatchableInterface` -- `Zend\Mvc\InjectApplicationEventInterface` -- `Zend\ServiceManager\ServiceLocatorAwareInterface` -- `Zend\EventManager\EventManagerAwareInterface` +* `Zend\Stdlib\DispatchableInterface` +* `Zend\Mvc\InjectApplicationEventInterface` +* `Zend\ServiceManager\ServiceLocatorAwareInterface` +* `Zend\EventManager\EventManagerAwareInterface` The composed `EventManager` will be configured to listen on the following contexts: -- `Zend\Stdlib\DispatchableInterface` -- `Zend\Mvc\Controller\AbstractRestfulController` -- `Zend\Mvc\Controller\AbstractController` +* `Zend\Stdlib\DispatchableInterface` +* `Zend\Mvc\Controller\AbstractRestfulController` +* `Zend\Mvc\Controller\AbstractController` Additionally, if you extend the class, it will listen on the extending class's name. diff --git a/doc/book/zend.mvc.intro.md b/doc/book/zend.mvc.intro.md index a3e260131..d4a89e44b 100644 --- a/doc/book/zend.mvc.intro.md +++ b/doc/book/zend.mvc.intro.md @@ -5,27 +5,27 @@ focusing on performance and flexibility. The MVC layer is built on top of the following components: -- `Zend\ServiceManager` - Zend Framework provides a set of default service definitions set up at +* `Zend\ServiceManager` - Zend Framework provides a set of default service definitions set up at `Zend\Mvc\Service`. The `ServiceManager` creates and configures your application instance and workflow. -- `Zend\EventManager` - The MVC is event driven. This component is used everywhere from initial +* `Zend\EventManager` - The MVC is event driven. This component is used everywhere from initial bootstrapping of the application, through returning response and request calls, to setting and retrieving routes and matched routes, as well as render views. -- `Zend\Http` - specifically the request and response objects, used within: -- `Zend\Stdlib\DispatchableInterface`. All "controllers" are simply dispatchable objects. +* `Zend\Http` - specifically the request and response objects, used within: +* `Zend\Stdlib\DispatchableInterface`. All "controllers" are simply dispatchable objects. Within the MVC layer, several sub-components are exposed: -- `Zend\Mvc\Router` contains classes pertaining to routing a request. In other words, it matches the +* `Zend\Mvc\Router` contains classes pertaining to routing a request. In other words, it matches the request to its respective controller (or dispatchable). -- `Zend\Http\PhpEnvironment` provides a set of decorators for the HTTP `Request` and `Response` +* `Zend\Http\PhpEnvironment` provides a set of decorators for the HTTP `Request` and `Response` objects that ensure the request is injected with the current environment (including query parameters, POST parameters, HTTP headers, etc.) -- `Zend\Mvc\Controller`, a set of abstract "controller" classes with basic responsibilities such as +* `Zend\Mvc\Controller`, a set of abstract "controller" classes with basic responsibilities such as event wiring, action dispatching, etc. -- `Zend\Mvc\Service` provides a set of `ServiceManager` factories and definitions for the default +* `Zend\Mvc\Service` provides a set of `ServiceManager` factories and definitions for the default application workflow. -- `Zend\Mvc\View` provides default wiring for renderer selection, view script resolution, helper +* `Zend\Mvc\View` provides default wiring for renderer selection, view script resolution, helper registration, and more; additionally, it provides a number of listeners that tie into the MVC workflow, providing features such as automated template name resolution, automated view model creation and injection, and more. @@ -162,15 +162,15 @@ The `view` directory contains view scripts related to your controllers. The `Application` has six basic dependencies. -- **configuration**, usually an array or object implementing `Traversable`. -- **ServiceManager** instance. -- **EventManager** instance, which, by default, is pulled from the `ServiceManager`, by the service +* **configuration**, usually an array or object implementing `Traversable`. +* **ServiceManager** instance. +* **EventManager** instance, which, by default, is pulled from the `ServiceManager`, by the service name "EventManager". -- **ModuleManager** instance, which, by default, is pulled from the `ServiceManager`, by the service +* **ModuleManager** instance, which, by default, is pulled from the `ServiceManager`, by the service name "ModuleManager". -- **Request** instance, which, by default, is pulled from the `ServiceManager`, by the service name +* **Request** instance, which, by default, is pulled from the `ServiceManager`, by the service name "Request". -- **Response** instance, which, by default, is pulled from the `ServiceManager`, by the service name +* **Response** instance, which, by default, is pulled from the `ServiceManager`, by the service name "Response". These may be satisfied at instantiation: @@ -196,13 +196,13 @@ $application = new Application($config, $serviceManager); Once you've done this, there are two additional actions you can take. The first is to "bootstrap" the application. In the default implementation, this does the following: -- Attaches the default route listener (`Zend\Mvc\RouteListener`). -- Attaches the default dispatch listener (`Zend\Mvc\DispatchListener`). -- Attaches the `ViewManager` listener (`Zend\Mvc\View\ViewManager`). -- Creates the `MvcEvent`, and injects it with the application, request, and response; it also +* Attaches the default route listener (`Zend\Mvc\RouteListener`). +* Attaches the default dispatch listener (`Zend\Mvc\DispatchListener`). +* Attaches the `ViewManager` listener (`Zend\Mvc\View\ViewManager`). +* Creates the `MvcEvent`, and injects it with the application, request, and response; it also retrieves the router (`Zend\Mvc\Router\Http\TreeRouteStack`) at this time and attaches it to the event. -- Triggers the "bootstrap" event. +* Triggers the "bootstrap" event. If you do not want these actions, or want to provide alternatives, you can do so by extending the `Application` class and/or simply coding what actions you want to occur. @@ -260,22 +260,21 @@ $configuration = include 'config/application.config.php'; Application::init($configuration)->run(); ``` -The `init()` method will basically do the following: -- Grabs the application configuration and pulls from the `service_manager` key, creating a -`ServiceManager` - instance with it and with the default services shipped with `Zend\Mvc`; +The `init()` method will basically do the following: -- Create a service named `ApplicationConfig` with the application configuration array; -- Grabs the `ModuleManager` service and load the modules; -- `bootstrap()`s the `Application` and returns its instance; +* Grabs the application configuration and pulls from the `service_manager` key, creating a +`ServiceManager` instance with it and with the default services shipped with `Zend\Mvc`; +* Create a service named `ApplicationConfig` with the application configuration array; +* Grabs the `ModuleManager` service and load the modules; +* `bootstrap()`s the `Application` and returns its instance; > ## Note If you use the `init()` method, you cannot specify a service with the name of 'ApplicationConfig' in your service manager config. This name is reserved to hold the array from application.config.php. The following services can only be overridden from application.config.php: -- `ModuleManager` -- `SharedEventManager` -- `EventManager` & `Zend\EventManager\EventManagerInterface` +* `ModuleManager` +* `SharedEventManager` +* `EventManager` & `Zend\EventManager\EventManagerInterface` All other services are configured after module loading, thus can be overridden by modules. You'll note that you have a great amount of control over the workflow. Using the `ServiceManager`, diff --git a/doc/book/zend.mvc.mvc-event.md b/doc/book/zend.mvc.mvc-event.md index cae39559e..14dc63ee8 100644 --- a/doc/book/zend.mvc.mvc-event.md +++ b/doc/book/zend.mvc.mvc-event.md @@ -8,37 +8,37 @@ Additionally, if your controllers implement the `Zend\Mvc\InjectApplicationEvent The `MvcEvent` adds accessors and mutators for the following: -- `Application` object. -- `Request` object. -- `Response` object. -- `Router` object. -- `RouteMatch` object. -- Result - usually the result of dispatching a controller. -- `ViewModel` object, typically representing the layout view model. +* `Application` object. +* `Request` object. +* `Response` object. +* `Router` object. +* `RouteMatch` object. +* Result - usually the result of dispatching a controller. +* `ViewModel` object, typically representing the layout view model. The methods it defines are: -- `setApplication($application)` -- `getApplication()` -- `setRequest($request)` -- `getRequest()` -- `setResponse($response)` -- `getResponse()` -- `setRouter($router)` -- `getRouter()` -- `setRouteMatch($routeMatch)` -- `getRouteMatch()` -- `setResult($result)` -- `getResult()` -- `setViewModel($viewModel)` -- `getViewModel()` -- `isError()` -- `setError()` -- `getError()` -- `getController()` -- `setController($name)` -- `getControllerClass()` -- `setControllerClass($class)` +* `setApplication($application)` +* `getApplication()` +* `setRequest($request)` +* `getRequest()` +* `setResponse($response)` +* `getResponse()` +* `setRouter($router)` +* `getRouter()` +* `setRouteMatch($routeMatch)` +* `getRouteMatch()` +* `setResult($result)` +* `getResult()` +* `setViewModel($viewModel)` +* `getViewModel()` +* `isError()` +* `setError()` +* `getError()` +* `getController()` +* `setController($name)` +* `getControllerClass()` +* `setControllerClass($class)` The `Application`, `Request`, `Response`, `Router`, and `ViewModel` are all injected during the `bootstrap` event. Following the `route` event, it will be injected also with the `RouteMatch` diff --git a/doc/book/zend.mvc.plugins.md b/doc/book/zend.mvc.plugins.md index 1c4fb229a..34bf95fa5 100644 --- a/doc/book/zend.mvc.plugins.md +++ b/doc/book/zend.mvc.plugins.md @@ -6,16 +6,15 @@ plugins. Additionally, you can register your own custom plugins with the manager The built-in plugins are: -- -\[Zend\\Mvc\\Controller\\Plugin\\AcceptableViewModelSelector\](zend.mvc.controller-plugins.acceptableviewmodelselector) -- \[Zend\\Mvc\\Controller\\Plugin\\FlashMessenger\](zend.mvc.controller-plugins.flashmessenger) -- \[Zend\\Mvc\\Controller\\Plugin\\Forward\](zend.mvc.controller-plugins.forward) -- \[Zend\\Mvc\\Controller\\Plugin\\Identity\](zend.mvc.controller-plugins.identity) -- \[Zend\\Mvc\\Controller\\Plugin\\Layout\](zend.mvc.controller-plugins.layout) -- \[Zend\\Mvc\\Controller\\Plugin\\Params\](zend.mvc.controller-plugins.params) -- \[Zend\\Mvc\\Controller\\Plugin\\PostRedirectGet\](zend.mvc.controller-plugins.postredirectget) -- \[Zend\\Mvc\\Controller\\Plugin\\Redirect\](zend.mvc.controller-plugins.redirect) -- \[Zend\\Mvc\\Controller\\Plugin\\Url\](zend.mvc.controller-plugins.url) +* \[Zend\\Mvc\\Controller\\Plugin\\AcceptableViewModelSelector\](zend.mvc.controller-plugins.acceptableviewmodelselector) +* \[Zend\\Mvc\\Controller\\Plugin\\FlashMessenger\](zend.mvc.controller-plugins.flashmessenger) +* \[Zend\\Mvc\\Controller\\Plugin\\Forward\](zend.mvc.controller-plugins.forward) +* \[Zend\\Mvc\\Controller\\Plugin\\Identity\](zend.mvc.controller-plugins.identity) +* \[Zend\\Mvc\\Controller\\Plugin\\Layout\](zend.mvc.controller-plugins.layout) +* \[Zend\\Mvc\\Controller\\Plugin\\Params\](zend.mvc.controller-plugins.params) +* \[Zend\\Mvc\\Controller\\Plugin\\PostRedirectGet\](zend.mvc.controller-plugins.postredirectget) +* \[Zend\\Mvc\\Controller\\Plugin\\Redirect\](zend.mvc.controller-plugins.redirect) +* \[Zend\\Mvc\\Controller\\Plugin\\Url\](zend.mvc.controller-plugins.url) If your controller implements the `setPluginManager`, `getPluginManager` and `plugin` methods, you can access these using their shortname via the `plugin()` method: @@ -233,10 +232,10 @@ controller. The plugin exposes a single method, `dispatch()`, which takes two arguments: -- `$name`, the name of the controller to invoke. This may be either the fully qualified class name, +* `$name`, the name of the controller to invoke. This may be either the fully qualified class name, or an alias defined and recognized by the `ServiceManager` instance attached to the invoking controller. -- `$params` is an optional array of parameters with which to seed a `RouteMatch` object for purposes +* `$params` is an optional array of parameters with which to seed a `RouteMatch` object for purposes of this specific request. Meaning the parameters will be matched by their key to the routing identifiers in the config (otherwise non-matching keys are ignored) @@ -312,7 +311,7 @@ The `Layout` plugin allows for changing layout templates from within controller It exposes a single method, `setTemplate()`, which takes one argument: -- `$template`, the name of the template to set. +* `$template`, the name of the template to set. As an example: @@ -380,9 +379,9 @@ session container and redirect the user to a GET request. This plugin can be invoked with two arguments: -- `$redirect`, a string containing the redirect location which can either be a named route or a URL, +* `$redirect`, a string containing the redirect location which can either be a named route or a URL, based on the contents of the second parameter. -- `$redirectToUrl`, a boolean that when set to TRUE, causes the first parameter to be treated as a +* `$redirectToUrl`, a boolean that when set to TRUE, causes the first parameter to be treated as a URL instead of a route name (this is required when redirecting to a URL instead of a route). This argument defaults to false. @@ -428,11 +427,11 @@ redirect. This plugin can be invoked with three arguments: -- `$form`: the form instance. -- `$redirect`: (Optional) a string containing the redirect location which can either be a named +* `$form`: the form instance. +* `$redirect`: (Optional) a string containing the redirect location which can either be a named route or a URL, based on the contents of the third parameter. If this argument is not provided, it will default to the current matched route. -- `$redirectToUrl`: (Optional) a boolean that when set to TRUE, causes the second parameter to be +* `$redirectToUrl`: (Optional) a boolean that when set to TRUE, causes the second parameter to be treated as a URL instead of a route name (this is required when redirecting to a URL instead of a route). This argument defaults to false. @@ -486,9 +485,9 @@ if ($form->isValid()) { Redirections are quite common operations within applications. If done manually, you will need to do the following steps: -- Assemble a url using the router -- Create and inject a "Location" header into the `Response` object, pointing to the assembled URL -- Set the status code of the `Response` object to one of the 3xx HTTP statuses. +* Assemble a url using the router +* Create and inject a "Location" header into the `Response` object, pointing to the assembled URL +* Set the status code of the `Response` object to one of the 3xx HTTP statuses. The `Redirect` plugin does this work for you. It offers three methods: diff --git a/doc/book/zend.mvc.quick-start.md b/doc/book/zend.mvc.quick-start.md index b4aa2c32f..17fc42699 100644 --- a/doc/book/zend.mvc.quick-start.md +++ b/doc/book/zend.mvc.quick-start.md @@ -35,12 +35,12 @@ my-application ### Manual Installation -- Download a tarball of the `ZendSkeletonApplication` repository: -- Zip: -- Tarball: -- Deflate the archive you selected and rename the parent directory according to your project needs; +* Download a tarball of the `ZendSkeletonApplication` repository: +* Zip: +* Tarball: +* Deflate the archive you selected and rename the parent directory according to your project needs; we use "my-application" throughout this document. -- Install Zend Framework, and either have its library on your PHP `include_path`, symlink the +* Install Zend Framework, and either have its library on your PHP `include_path`, symlink the library into your project's "library", or install it directly into your application using Pyrus. ## Create a New Module @@ -57,8 +57,8 @@ Additional functionality will be provided by creating new modules. To get you started with modules, we recommend using the `ZendSkeletonModule` as a base. Download it from here: -- Zip: -- Tarball: +* Zip: +* Tarball: Deflate the package, and rename the directory "ZendSkeletonModule" to reflect the name of the new module you want to create; when done, move the module into your new project's `module/` directory. @@ -136,17 +136,17 @@ need to implement a `dispatch()` method that takes minimally a `Request` object In practice, though, this would mean writing logic to branch based on matched routing within every controller. As such, we've created two base controller classes for you to start with: -- `Zend\Mvc\Controller\AbstractActionController` allows routes to match an "action". When matched, a +* `Zend\Mvc\Controller\AbstractActionController` allows routes to match an "action". When matched, a method named after the action will be called by the controller. As an example, if you had a route that returned "foo" for the "action" key, the "fooAction" method would be invoked. -- `Zend\Mvc\Controller\AbstractRestfulController` introspects the `Request` to determine what HTTP +* `Zend\Mvc\Controller\AbstractRestfulController` introspects the `Request` to determine what HTTP method was used, and calls a method according to that. -- `GET` will call either the `getList()` method, or, if an "id" was matched during routing, the +* `GET` will call either the `getList()` method, or, if an "id" was matched during routing, the `get()` method (with that identifer value). -- `POST` will call the `create()` method, passing in the `$_POST` values. -- `PUT` expects an "id" to be matched during routing, and will call the `update()` method, passing +* `POST` will call the `create()` method, passing in the `$_POST` values. +* `PUT` expects an "id" to be matched during routing, and will call the `update()` method, passing in the identifier, and any data found in the raw post body. -- `DELETE` expects an "id" to be matched during routing, and will call the `delete()` method. +* `DELETE` expects an "id" to be matched during routing, and will call the `delete()` method. To get started, we'll simply create a "hello world"-style controller, with a single action. First, create the directory `src//Controller`, and then create the file `HelloController.php` @@ -171,11 +171,11 @@ class HelloController extends AbstractActionController So, what are we doing here? -- We're creating an action controller. -- We're defining an action, "world". -- We're pulling a message from the query parameters (yes, this is a superbly bad idea in production! +* We're creating an action controller. +* We're defining an action, "world". +* We're pulling a message from the query parameters (yes, this is a superbly bad idea in production! Always sanitize your inputs!). -- We're returning a ViewModel with an array of values to be processed later. +* We're returning a ViewModel with an array of values to be processed later. We return a `ViewModel`. The view layer will use this when rendering the view, pulling variables and the template name from it. By default, you can omit the template name, and it will resolve to diff --git a/doc/book/zend.mvc.routing.md b/doc/book/zend.mvc.routing.md index 6af73646f..f960c88d6 100644 --- a/doc/book/zend.mvc.routing.md +++ b/doc/book/zend.mvc.routing.md @@ -136,11 +136,11 @@ a B-tree algorithm to match routes. As such, you register a single route with ma A `TreeRouteStack` will consist of the following configuration: -- A base "route", which describes the base match needed, the root of the tree. -- An optional "route\_plugins", which is a configured `Zend\Mvc\Router\RoutePluginManager` that can +* A base "route", which describes the base match needed, the root of the tree. +* An optional "route\_plugins", which is a configured `Zend\Mvc\Router\RoutePluginManager` that can lazy-load routes. -- The option "may\_terminate", which hints to the router that no other segments will follow it. -- An optional "child\_routes" array, which contains additional routes that stem from the base +* The option "may\_terminate", which hints to the router that no other segments will follow it. +* An optional "child\_routes" array, which contains additional routes that stem from the base "route" (i.e., build from it). Each child route can itself be a `TreeRouteStack` if desired; in fact, the `Part` route works exactly this way. @@ -161,8 +161,8 @@ Zend Framework 2.0 ships with the following HTTP route types. The `Hostname` route attempts to match the hostname registered in the request against specific criteria. Typically, this will be in one of the following forms: -- "subdomain.domain.tld" -- ":subdomain.domain.tld" +* "subdomain.domain.tld" +* ":subdomain.domain.tld" In the above, the second route would return a "subdomain" key as part of the route match. @@ -306,11 +306,11 @@ $route = Part::factory(array( The above would match the following: -- "/" would load the "Index" controller, "index" action. -- "/blog" would load the "Blog" controller, "index" action. -- "/blog/rss" would load the "Blog" controller, "rss" action. -- "/blog/rss/sub" would load the "Blog" controller, "subrss" action. -- "/forum" would load the "Forum" controller, "index" action. +* "/" would load the "Index" controller, "index" action. +* "/blog" would load the "Blog" controller, "index" action. +* "/blog/rss" would load the "Blog" controller, "rss" action. +* "/blog/rss/sub" would load the "Blog" controller, "subrss" action. +* "/forum" would load the "Forum" controller, "index" action. You may use any route type as a child route of a `Part` route. @@ -675,13 +675,13 @@ return array( The above would match the following: -- `modules.zendframework.com` would dispatch the `Index` controller's `index` action of the `Module` +* `modules.zendframework.com` would dispatch the `Index` controller's `index` action of the `Module` module. -- `modules.ci.zendframework.com` would dispatch the `Index` controller's `index` action of the +* `modules.ci.zendframework.com` would dispatch the `Index` controller's `index` action of the `Module` module. -- `packages.zendframework.com` would dispatch the `Index` controller's `index` action of the +* `packages.zendframework.com` would dispatch the `Index` controller's `index` action of the `Package` module. -- `packages.dev.zendframework.com` would dispatch the `Index` controller's `index` action of the +* `packages.dev.zendframework.com` would dispatch the `Index` controller's `index` action of the `Package` module. The `Url` controller plugin or view helper may be used to generate URLs following the above example: diff --git a/doc/book/zend.mvc.send-response-event.md b/doc/book/zend.mvc.send-response-event.md index 190f3cd95..52a600934 100644 --- a/doc/book/zend.mvc.send-response-event.md +++ b/doc/book/zend.mvc.send-response-event.md @@ -6,12 +6,12 @@ to update the response object, by setting headers and content. The methods it defines are: -- `setResponse($response)` -- `getResponse()` -- `setContentSent()` -- `contentSent()` -- `setHeadersSent()` -- `headersSent()` +* `setResponse($response)` +* `getResponse()` +* `setContentSent()` +* `contentSent()` +* `setHeadersSent()` +* `headersSent()` ## Listeners diff --git a/doc/book/zend.mvc.services.md b/doc/book/zend.mvc.services.md index d19e74556..79bb5afbc 100644 --- a/doc/book/zend.mvc.services.md +++ b/doc/book/zend.mvc.services.md @@ -31,22 +31,22 @@ system from within the modules, overriding any default configuration in these MV As a quick review, the following service types may be configured: -- **Invokable services**, which map a service name to a class that has no constructor or a +* **Invokable services**, which map a service name to a class that has no constructor or a constructor that accepts no arguments. -- **Factories**, which map a service name to a factory which will create and return an object. A +* **Factories**, which map a service name to a factory which will create and return an object. A factory receives the service manager as an argument, and may be any PHP callable, or a class or object that implements `Zend\ServiceManager\FactoryInterface`. -- **Abstract factories**, which are factories that can create any number of named services that +* **Abstract factories**, which are factories that can create any number of named services that share the same instantiation pattern; examples include database adapters, cache adapters, loggers, etc. The factory receives the service manager as an argument, the resolved service name, and the requested service name; it **must** be a class or object implementing `Zend\ServiceManager\AbstractFactoryInterface`. See the section on abstract factories <zend.mvc.services.abstract-factories> for configuration information. -- **Aliases**, which alias one service name to another. Aliases can also reference other aliases. -- **Initializers**, which receive the newly created instance and the service manager, and which can +* **Aliases**, which alias one service name to another. Aliases can also reference other aliases. +* **Initializers**, which receive the newly created instance and the service manager, and which can be used to perform additional initialization tasks. The most common use case is to test the instance against specific "Aware" interfaces, and, if matching, inject them with the appropriate service. -- **Plugin managers**, which are specialized service managers used to manage objects that are of a +* **Plugin managers**, which are specialized service managers used to manage objects that are of a related type, such as view helpers, controller plugins, controllers, etc. Plugin managers accept configuration just like service managers, and as such can compose invokable services, factories, abstract factories, aliases, and initializers. They are also `ServiceLocatorAware`, and will be @@ -57,206 +57,191 @@ access to application-level services when needed. See the heading Plugin manager The application service manager is referenced directly during bootstrapping, and has the following services configured out of the box. -- **Invokable services** -- `DispatchListener`, mapping to `Zend\Mvc\DispatchListener`. -- `RouteListener`, mapping to `Zend\Mvc\RouteListener`. -- `SendResponseListener`, mapping to `Zend\Mvc\SendResponseListener`. -- `SharedEventManager`, mapping to `Zend\EventManager\SharedEventManager`. -- **Factories** -- `Application`, mapping to `Zend\Mvc\Service\ApplicationFactory`. -- `Config`, mapping to `Zend\Mvc\Service\ConfigFactory`. Internally, this pulls the `ModuleManager` +* **Invokable services** + * `DispatchListener`, mapping to `Zend\Mvc\DispatchListener`. + * `RouteListener`, mapping to `Zend\Mvc\RouteListener`. + * `SendResponseListener`, mapping to `Zend\Mvc\SendResponseListener`. + * `SharedEventManager`, mapping to `Zend\EventManager\SharedEventManager`. +* **Factories** + * `Application`, mapping to `Zend\Mvc\Service\ApplicationFactory`. + * `Config`, mapping to `Zend\Mvc\Service\ConfigFactory`. Internally, this pulls the `ModuleManager` service, and calls its `loadModules()` method, and retrieves the merged configuration from the module event. As such, this service contains the entire, merged application configuration. -- `ControllerManager`, mapping to `Zend\Mvc\Service\ControllerLoaderFactory`. This creates an + * `ControllerManager`, mapping to `Zend\Mvc\Service\ControllerLoaderFactory`. This creates an instance of `Zend\Mvc\Controller\ControllerManager`, passing the service manager instance. - - Additionally, it uses the `DiStrictAbstractServiceFactory` service -- effectively allowing +Additionally, it uses the `DiStrictAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve your controllers. If you want to use `Zend\Di` to retrieve your controllers, you must white-list them in your DI configuration under the `allowed_controllers` key (otherwise, they will just be ignored). - - The `ControllerManager` will add an initializer that will do the following: - - > - If the controller implements the `Zend\ServiceManager\ServiceLocatorAwareInterface` +The `ControllerManager` will add an initializer that will do the following: + * If the controller implements the `Zend\ServiceManager\ServiceLocatorAwareInterface` interface, an instance of the `ServiceManager` will be injected into it. - > - If the controller implements the `Zend\EventManager\EventManagerAwareInterface` + * If the controller implements the `Zend\EventManager\EventManagerAwareInterface` interface, an instance of the `EventManager` will be injected into it. - > - Finally, an initializer will inject it with the `ControllerPluginManager` service, as + * Finally, an initializer will inject it with the `ControllerPluginManager` service, as long as the `setPluginManager` method is implemented. - -- `ControllerPluginManager`, mapping to `Zend\Mvc\Service\ControllerPluginManagerFactory`. This + * `ControllerPluginManager`, mapping to `Zend\Mvc\Service\ControllerPluginManagerFactory`. This instantiates the `Zend\Mvc\Controller\PluginManager` instance, passing it the service manager instance. It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve your controller plugins <zend.mvc.controller-plugins>. - - It registers a set of default controller plugins, and contains an initializer for injecting +It registers a set of default controller plugins, and contains an initializer for injecting plugins with the current controller. - -- `ConsoleAdapter`, mapping to `Zend\Mvc\Service\ConsoleAdapterFactory`. This grabs the `Config` + * `ConsoleAdapter`, mapping to `Zend\Mvc\Service\ConsoleAdapterFactory`. This grabs the `Config` service, pulls from the `console` key, and do the following: -- If the `adapter` subkey is present, it is used to get the adapter instance, otherwise, + * If the `adapter` subkey is present, it is used to get the adapter instance, otherwise, `Zend\Console\Console::detectBestAdapter()` will be called to configure an adapter instance. -- If the `charset` subkey is present, the is used to set the adapter charset. -- `ConsoleRouter`, mapping to `Zend\Mvc\Service\RouterFactory`. This grabs the `Config` service, and + * If the `charset` subkey is present, the is used to set the adapter charset. + * `ConsoleRouter`, mapping to `Zend\Mvc\Service\RouterFactory`. This grabs the `Config` service, and pulls from the `console` key and `router` subkey, configuring a `Zend\Mvc\Router\Console\SimpleRouteStack` instance. -- `ConsoleViewManager`, mapping to `Zend\Mvc\Service\ConsoleViewManagerFactory`. This creates and + * `ConsoleViewManager`, mapping to `Zend\Mvc\Service\ConsoleViewManagerFactory`. This creates and returns an instance of `Zend\Mvc\View\Console\ViewManager`, which in turn registers and initializes a number of console-specific view services. -- `DependencyInjector`, mapping to `Zend\Mvc\Service\DiFactory`. This pulls the `Config` service, + * `DependencyInjector`, mapping to `Zend\Mvc\Service\DiFactory`. This pulls the `Config` service, and looks for a "di" key; if found, that value is used to configure a new `Zend\Di\Di` instance. -- `DiAbstractServiceFactory`, mapping to `Zend\Mvc\Service\DiAbstractServiceFactoryFactory`. This + * `DiAbstractServiceFactory`, mapping to `Zend\Mvc\Service\DiAbstractServiceFactoryFactory`. This creates an instance of `Zend\ServiceManager\Di\DiAbstractServiceFactory` injecting the `Di` service instance. That instance is attached to the service manager as an abstract factory -- effectively enabling DI as a fallback for providing services. -- `DiServiceInitializer`, mapping to `Zend\Mvc\Service\DiServiceInitializerFactory`. This creates an + * `DiServiceInitializer`, mapping to `Zend\Mvc\Service\DiServiceInitializerFactory`. This creates an instance of `Zend\ServiceManager\Di\DiServiceInitializer` injecting the `Di` service and the service manager itself. -- `DiStrictAbstractServiceFactory`, mapping to + * `DiStrictAbstractServiceFactory`, mapping to `Zend\Mvc\Service\DiStrictAbstractServiceFactoryFactory`. This creates an instance of `Zend\Mvc\Service\DiStrictAbstractServiceFactoryFactory` injecting the `Di` service instance. -- `EventManager`, mapping to `Zend\Mvc\Service\EventManagerFactory`. This factory returns a new + * `EventManager`, mapping to `Zend\Mvc\Service\EventManagerFactory`. This factory returns a new instance of `Zend\EventManager\EventManager` on each request. This service is not shared by default, allowing the ability to have an `EventManager` per service, with a shared `SharedEventManager` injected in each. -- `FilterManager`, mapping to `Zend\Mvc\Service\FilterManagerFactory`. This instantiates the + * `FilterManager`, mapping to `Zend\Mvc\Service\FilterManagerFactory`. This instantiates the `Zend\Filter\FilterPluginManager` instance, passing it the service manager instance -- this is used to manage filters for the \[filter chains\](zend.filter.filter\_chains). It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve filters. -- `FormElementManager`, mapping to `Zend\Mvc\Service\FormElementManagerFactory`. This instantiates + * `FormElementManager`, mapping to `Zend\Mvc\Service\FormElementManagerFactory`. This instantiates the `Zend\Form\FormElementManager` instance, passing it the service manager instance -- this is used to manage \[form elements\](zend.form.elements.intro). It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve form elements. -- `HttpRouter`, mapping to `Zend\Mvc\Service\RouterFactory`. This grabs the `Config` service, and + * `HttpRouter`, mapping to `Zend\Mvc\Service\RouterFactory`. This grabs the `Config` service, and pulls from the `router` key, configuring a `Zend\Mvc\Router\Http\TreeRouteStack` instance. -- `HttpViewManager`, mapping to `Zend\Mvc\Service\HttpViewManagerFactory`. This creates and returns + * `HttpViewManager`, mapping to `Zend\Mvc\Service\HttpViewManagerFactory`. This creates and returns an instance of `Zend\Mvc\View\Http\ViewManager`, which in turn registers and initializes a number of HTTP-specific view services. -- `HydratorManager`, mapping to `Zend\Mvc\Service\HydratorManagerFactory`. This creates and returns + * `HydratorManager`, mapping to `Zend\Mvc\Service\HydratorManagerFactory`. This creates and returns an instance of `Zend\Stdlib\Hydrator\HydratorPluginManager`, which can be used to manage and persist hydrator instances. -- `InputFilterManager`, mapping to `Zend\Mvc\Service\InputFilterManagerFactory`. This creates and + * `InputFilterManager`, mapping to `Zend\Mvc\Service\InputFilterManagerFactory`. This creates and returns an instance of `Zend\InputFilter\InputFilterPluginManager`, which can be used to manage and persist input filter instances. -- `ModuleManager`, mapping to `Zend\Mvc\Service\ModuleManagerFactory`. - - This is perhaps the most complex factory in the MVC stack. It expects that an + * `ModuleManager`, mapping to `Zend\Mvc\Service\ModuleManagerFactory`. +This is perhaps the most complex factory in the MVC stack. It expects that an `ApplicationConfig` service has been injected, with keys for `module_listener_options` and `modules`; see the quick start for samples. - - It instantiates an instance of `Zend\ModuleManager\Listener\DefaultListenerAggregate`, using +It instantiates an instance of `Zend\ModuleManager\Listener\DefaultListenerAggregate`, using the "module\_listener\_options" retrieved. Checks if a service with the name `ServiceListener` exists, otherwise it sets a factory with that name mapping to `Zend\Mvc\Service\ServiceListenerFactory`. A bunch of service listeners will be added to the `ServiceListener`, like listeners for the `getServiceConfig`, `getControllerConfig`, `getControllerPluginConfig`, `getViewHelperConfig` module methods. - - Next, it retrieves the `EventManager` service, and attaches the above listeners. - - It instantiates a `Zend\ModuleManager\ModuleEvent` instance, setting the "ServiceManager" +Next, it retrieves the `EventManager` service, and attaches the above listeners. +It instantiates a `Zend\ModuleManager\ModuleEvent` instance, setting the "ServiceManager" parameter to the service manager object. - - Finally, it instantiates a `Zend\ModuleManager\ModuleManager` instance, and injects the +Finally, it instantiates a `Zend\ModuleManager\ModuleManager` instance, and injects the `EventManager` and `ModuleEvent`. - -- `MvcTranslator`, mapping to `Zend\Mvc\Service\TranslatorServiceFactory`, and returning an instance + * `MvcTranslator`, mapping to `Zend\Mvc\Service\TranslatorServiceFactory`, and returning an instance of `Zend\Mvc\I18n\Translator`, which extends `Zend\I18n\Translator\Translator` and implements `Zend\Validator\Translator\TranslatorInterface`, allowing the instance to be used anywhere a translator may be required in the framework. -- `PaginatorPluginManager`, mapping to `Zend\Mvc\Service\PaginatorPluginManagerFactory`. This + * `PaginatorPluginManager`, mapping to `Zend\Mvc\Service\PaginatorPluginManagerFactory`. This instantiates the `Zend\Paginator\AdapterPluginManager` instance, passing it the service manager instance -- this is used to manage paginator adapters <zend.paginator.usage.paginating.adapters>. It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve paginator adapters. -- `Request`, mapping to `Zend\Mvc\Service\RequestFactory`. The factory is used to create and return + * `Request`, mapping to `Zend\Mvc\Service\RequestFactory`. The factory is used to create and return a request instance, according to the current environment. If the current environment is `cli`, it will create a `Zend\Console\Request`, or a `Zend\Http\PhpEnvironment\Request` if the current environment is HTTP. -- `Response`, mapping to `Zend\Mvc\Service\ResponseFactory`. The factory is used to create and + * `Response`, mapping to `Zend\Mvc\Service\ResponseFactory`. The factory is used to create and return a response instance, according to the current environment. If the current environment is `cli`, it will create a `Zend\Console\Response`, or a `Zend\Http\PhpEnvironment\Response` if the current environment is HTTP. -- `Router`, mapping to `Zend\Mvc\Service\RouterFactory`. If in a console enviroment, this will + * `Router`, mapping to `Zend\Mvc\Service\RouterFactory`. If in a console enviroment, this will behave the same way as the `ConsoleRouter` service, if not, it will behave the same way as `HttpRouter` service. -- `RoutePluginManager`, mapping to `Zend\Mvc\Service\RoutePluginManagerFactory`. This instantiates + * `RoutePluginManager`, mapping to `Zend\Mvc\Service\RoutePluginManagerFactory`. This instantiates the `Zend\Mvc\Router\RoutePluginManager` instance, passing it the service manager instance -- this is used to manage \[route types\](zend.mvc.routing.http-route-types). It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve route types. -- `SerializerAdapterManager`, mapping to `Zend\Mvc\Service\SerializerAdapterPluginManagerFactory`, + * `SerializerAdapterManager`, mapping to `Zend\Mvc\Service\SerializerAdapterPluginManagerFactory`, which returns an instance of `Zend\Serializer\AdapterPluginManager`. This is a plugin manager for managing serializer adapter instances. -- `ServiceListener`, mapping to `Zend\Mvc\Service\ServiceListenerFactory`. The factory is used to + * `ServiceListener`, mapping to `Zend\Mvc\Service\ServiceListenerFactory`. The factory is used to instantiate the `ServiceListener`, while allowing easy extending. It checks if a service with the name `ServiceListenerInterface` exists, which must implement `Zend\ModuleManager\Listener\ServiceListenerInterface`, before instantiating the default `ServiceListener`. - - In addition to this, it retrieves the `ApplicationConfig` and looks for the +In addition to this, it retrieves the `ApplicationConfig` and looks for the `service_listener_options` key. This allows you to register own listeners for module methods and configuration keys to create an own service manager; see the application configuration - options <zend.mvc.services.app-config> for samples. - -- `ValidatorManager`, mapping to `Zend\Mvc\Service\ValidatorManagerFactory`. This instantiates the +options <zend.mvc.services.app-config> for samples. + * `ValidatorManager`, mapping to `Zend\Mvc\Service\ValidatorManagerFactory`. This instantiates the `Zend\Validator\ValidatorPluginManager` instance, passing it the service manager instance -- this is used to manage \[validators\](zend.validator.set). It also uses the `DiAbstractServiceFactory` service -- effectively allowing you to fall back to DI in order to retrieve validators. -- `ViewFeedRenderer`, mapping to `Zend\Mvc\Service\ViewFeedRendererFactory`, which returns an + * `ViewFeedRenderer`, mapping to `Zend\Mvc\Service\ViewFeedRendererFactory`, which returns an instance of `Zend\View\Renderer\FeedRenderer`, used to render feeds. -- `ViewFeedStrategy`, mapping to `Zend\Mvc\Service\ViewFeedStrategyFactory`, which returns an + * `ViewFeedStrategy`, mapping to `Zend\Mvc\Service\ViewFeedStrategyFactory`, which returns an instance of `Zend\View\Strategy\FeedStrategy`, used to select the `ViewFeedRenderer` given the appropriate criteria. -- `ViewHelperManager`, mapping to `Zend\Mvc\Service\ViewHelperManagerFactory`, which returns an + * `ViewHelperManager`, mapping to `Zend\Mvc\Service\ViewHelperManagerFactory`, which returns an instance of `Zend\View\HelperManager`. This is a plugin manager for managing view helper instances. -- `ViewJsonRenderer`, mapping to `Zend\Mvc\Service\ViewJsonRendererFactory`, which returns an + * `ViewJsonRenderer`, mapping to `Zend\Mvc\Service\ViewJsonRendererFactory`, which returns an instance of `Zend\View\Renderer\JsonRenderer`, used to render JSON structures. -- `ViewJsonStrategy`, mapping to `Zend\Mvc\Service\ViewJsonStrategyFactory`, which returns an + * `ViewJsonStrategy`, mapping to `Zend\Mvc\Service\ViewJsonStrategyFactory`, which returns an instance of `Zend\View\Strategy\JsonStrategy`, used to select the `ViewJsonRenderer` given the appropriate criteria. -- `ViewManager`, mapping to `Zend\Mvc\Service\ViewManagerFactory`. The factory is used to create and + * `ViewManager`, mapping to `Zend\Mvc\Service\ViewManagerFactory`. The factory is used to create and return a view manager, according to the current environment. If the current environment is `cli`, it will create a `Zend\Mvc\View\Console\ViewManager`, or a `Zend\Mvc\View\Http\ViewManager` if the current environment is HTTP. -- `ViewResolver`, mapping to `Zend\Mvc\Service\ViewResolverFactory`, which creates and returns the + * `ViewResolver`, mapping to `Zend\Mvc\Service\ViewResolverFactory`, which creates and returns the aggregate view resolver. It also attaches the `ViewTemplateMapResolver` and `ViewTemplatePathStack` services to it. -- `ViewTemplateMapResolver`, mapping to `Zend\Mvc\Service\ViewTemplateMapResolverFactory` which + * `ViewTemplateMapResolver`, mapping to `Zend\Mvc\Service\ViewTemplateMapResolverFactory` which creates, configures and returns the `Zend\View\Resolver\TemplateMapResolver`. -- `ViewTemplatePathStack`, mapping to `Zend\Mvc\Service\ViewTemplatePathStackFactory` which creates, + * `ViewTemplatePathStack`, mapping to `Zend\Mvc\Service\ViewTemplatePathStackFactory` which creates, configures and returns the `Zend\View\Resolver\TemplatePathStack`. - -- **Abstract factories** -- `Zend\Cache\Service\StorageCacheAbstractServiceFactory` (opt-in; registered by default in the +* **Abstract factories** + * `Zend\Cache\Service\StorageCacheAbstractServiceFactory` (opt-in; registered by default in the skeleton application). -- `Zend\Db\Adapter\AdapterAbstractServiceFactory` (opt-in). -- `Zend\Form\FormAbstractServiceFactory` is registered by default. -- `Zend\Log\LoggerAbstractServiceFactory` (opt-in; registered by default in the skeleton + * `Zend\Db\Adapter\AdapterAbstractServiceFactory` (opt-in). + * `Zend\Form\FormAbstractServiceFactory` is registered by default. + * `Zend\Log\LoggerAbstractServiceFactory` (opt-in; registered by default in the skeleton application). -- **Aliases** -- `Configuration`, mapping to the `Config` service. -- `Console`, mapping to the `ConsoleAdapter` service. -- `Di`, mapping to the `DependencyInjector` service. -- `Zend\Di\LocatorInterface`, mapping to the `DependencyInjector` service. -- `Zend\EventManager\EventManagerInterface`, mapping to the `EventManager` service. This is mainly +* **Aliases** + * `Configuration`, mapping to the `Config` service. + * `Console`, mapping to the `ConsoleAdapter` service. + * `Di`, mapping to the `DependencyInjector` service. + * `Zend\Di\LocatorInterface`, mapping to the `DependencyInjector` service. + * `Zend\EventManager\EventManagerInterface`, mapping to the `EventManager` service. This is mainly to ensure that when falling through to DI, classes are still injected via the `ServiceManager`. -- `Zend\Mvc\Controller\PluginManager`, mapping to the `ControllerPluginManager` service. This is + * `Zend\Mvc\Controller\PluginManager`, mapping to the `ControllerPluginManager` service. This is mainly to ensure that when falling through to DI, classes are still injected via the `ServiceManager`. -- `Zend\View\Resolver\TemplateMapResolver`, mapping to the `ViewTemplateMapResolver` service. -- `Zend\View\Resolver\TemplatePathStack`, mapping to the `ViewTemplatePathStack` service. -- `Zend\View\Resolver\AggregateResolver`, mapping to the `ViewResolver` service. -- `Zend\View\Resolver\ResolverInterface`, mapping to the `ViewResolver` service. -- **Initializers** -- For objects that implement `Zend\EventManager\EventManagerAwareInterface`, the `EventManager` + * `Zend\View\Resolver\TemplateMapResolver`, mapping to the `ViewTemplateMapResolver` service. + * `Zend\View\Resolver\TemplatePathStack`, mapping to the `ViewTemplatePathStack` service. + * `Zend\View\Resolver\AggregateResolver`, mapping to the `ViewResolver` service. + * `Zend\View\Resolver\ResolverInterface`, mapping to the `ViewResolver` service. +* **Initializers** + * For objects that implement `Zend\EventManager\EventManagerAwareInterface`, the `EventManager` service will be retrieved and injected. This service is **not** shared, though each instance it creates is injected with a shared instance of `SharedEventManager`. -- For objects that implement `Zend\ServiceManager\ServiceLocatorAwareInterface`, the + * For objects that implement `Zend\ServiceManager\ServiceLocatorAwareInterface`, the `ServiceManager` will inject itself into the object. -- The `ServiceManager` registers itself as the `ServiceManager` service, and aliases itself to the + * The `ServiceManager` registers itself as the `ServiceManager` service, and aliases itself to the class names `Zend\ServiceManager\ServiceLocatorInterface` and `Zend\ServiceManager\ServiceManager`. ## Abstract Factories @@ -384,25 +369,25 @@ See the \[log documentation\](zend.log.overview) for more configuration options. The following plugin managers are configured by default: -- **ControllerManager**, corresponding to `Zend\Mvc\Controller\ControllerManager`, and used to +* **ControllerManager**, corresponding to `Zend\Mvc\Controller\ControllerManager`, and used to manage controller instances. -- **ControllerPluginManager**, corresponding to `Zend\Mvc\Controller\PluginManager`, and used to +* **ControllerPluginManager**, corresponding to `Zend\Mvc\Controller\PluginManager`, and used to manage controller plugin instances. -- **FilterManager**, corresponding to `Zend\Filter\FilterPluginManager`, and used to manage filter +* **FilterManager**, corresponding to `Zend\Filter\FilterPluginManager`, and used to manage filter instances. -- **FormElementManager**, corresponding to `Zend\Form\FormElementManager`, and used to manage +* **FormElementManager**, corresponding to `Zend\Form\FormElementManager`, and used to manage instances of form elements and fieldsets. -- **HydratorManager**, corresponding to `Zend\Stdlib\Hydrator\HydratorPluginManager`, and used to +* **HydratorManager**, corresponding to `Zend\Stdlib\Hydrator\HydratorPluginManager`, and used to manage hydrator instances. -- **InputFilterManager**, corresponding to `Zend\InputFilter\InputFilterPluginManager`, and used to +* **InputFilterManager**, corresponding to `Zend\InputFilter\InputFilterPluginManager`, and used to manage input filter instances. -- **RoutePluginManager**, corresponding to `Zend\Mvc\Router\RoutePluginManager`, and used to manage +* **RoutePluginManager**, corresponding to `Zend\Mvc\Router\RoutePluginManager`, and used to manage route instances. -- **SerializerAdapterManager**, corresponding to `Zend\Serializer\AdapterPluginManager`, and used to +* **SerializerAdapterManager**, corresponding to `Zend\Serializer\AdapterPluginManager`, and used to manage serializer instances. -- **ValidatorManager**, corresponding to `Zend\Validator\ValidatorPluginManager`, and used to manage +* **ValidatorManager**, corresponding to `Zend\Validator\ValidatorPluginManager`, and used to manage validator instances. -- **ViewHelperManager**, corresponding to `Zend\View\HelperPluginManager`, and used to manage view +* **ViewHelperManager**, corresponding to `Zend\View\HelperPluginManager`, and used to manage view helper instances. As noted in the previous section, all plugin managers share the same configuration and service types @@ -423,42 +408,42 @@ Configuration for all members of the `ViewManager` fall under the `view_manager` and expect values as noted below. The following services are created and managed by the `ViewManager`: -- `ViewHelperManager`, representing and aliased to `Zend\View\HelperPluginManager`. It is seeded +* `ViewHelperManager`, representing and aliased to `Zend\View\HelperPluginManager`. It is seeded with the `ServiceManager`. Created via the `Zend\Mvc\Service\ViewHelperManagerFactory`. -- The `Router` service is retrieved, and injected into the `Url` helper. -- If the `base_path` key is present, it is used to inject the `BasePath` view helper; otherwise, the + * The `Router` service is retrieved, and injected into the `Url` helper. + * If the `base_path` key is present, it is used to inject the `BasePath` view helper; otherwise, the `Request` service is retrieved, and the value of its `getBasePath()` method is used. -- If the `base_path_console` key is present, it is used to inject the `BasePath` view helper for + * If the `base_path_console` key is present, it is used to inject the `BasePath` view helper for console requests; otherwise, the `Request` service is retrieved, and the value of its `getBasePath()` method is used. This can be useful for sending urls in emails via a cronjob. -- If the `doctype` key is present, it will be used to set the value of the `Doctype` view helper. -- `ViewTemplateMapResolver`, representing and aliased to `Zend\View\Resolver\TemplateMapResolver`. + * If the `doctype` key is present, it will be used to set the value of the `Doctype` view helper. +* `ViewTemplateMapResolver`, representing and aliased to `Zend\View\Resolver\TemplateMapResolver`. If a `template_map` key is present, it will be used to seed the template map. -- `ViewTemplatePathStack`, representing and aliased to `Zend\View\Resolver\TemplatePathStack`. -- If a `template_path_stack` key is present, it will be used to seed the stack. -- If a `default_template_suffix` key is present, it will be used as the default suffix for template +* `ViewTemplatePathStack`, representing and aliased to `Zend\View\Resolver\TemplatePathStack`. + * If a `template_path_stack` key is present, it will be used to seed the stack. + * If a `default_template_suffix` key is present, it will be used as the default suffix for template scripts resolving. -- `ViewResolver`, representing and aliased to `Zend\View\Resolver\AggregateResolver` and +* `ViewResolver`, representing and aliased to `Zend\View\Resolver\AggregateResolver` and `Zend\View\Resolver\ResolverInterface`. It is seeded with the `ViewTemplateMapResolver` and `ViewTemplatePathStack` services as resolvers. -- `ViewRenderer`, representing and aliased to `Zend\View\Renderer\PhpRenderer` and +* `ViewRenderer`, representing and aliased to `Zend\View\Renderer\PhpRenderer` and `Zend\View\Renderer\RendererInterface`. It is seeded with the `ViewResolver` and `ViewHelperManager` services. Additionally, the `ViewModel` helper gets seeded with the `ViewModel` as its root (layout) model. -- `ViewPhpRendererStrategy`, representing and aliased to `Zend\View\Strategy\PhpRendererStrategy`. +* `ViewPhpRendererStrategy`, representing and aliased to `Zend\View\Strategy\PhpRendererStrategy`. It gets seeded with the `ViewRenderer` service. -- `View`, representing and aliased to `Zend\View\View`. It gets seeded with the `EventManager` +* `View`, representing and aliased to `Zend\View\View`. It gets seeded with the `EventManager` service, and attaches the `ViewPhpRendererStrategy` as an aggregate listener. -- `DefaultRenderingStrategy`, representing and aliased to `Zend\Mvc\View\DefaultRenderingStrategy`. +*`DefaultRenderingStrategy`, representing and aliased to `Zend\Mvc\View\DefaultRenderingStrategy`. If the `layout` key is present, it is used to seed the strategy's layout template. It is seeded with the `View` service. -- `ExceptionStrategy`, representing and aliased to `Zend\Mvc\View\ExceptionStrategy`. If the +* `ExceptionStrategy`, representing and aliased to `Zend\Mvc\View\ExceptionStrategy`. If the `display_exceptions` or `exception_template` keys are present, they are used to configure the strategy. -- `RouteNotFoundStrategy`, representing and aliased to `Zend\Mvc\View\RouteNotFoundStrategy` and +* `RouteNotFoundStrategy`, representing and aliased to `Zend\Mvc\View\RouteNotFoundStrategy` and `404Strategy`. If the `display_not_found_reason` or `not_found_template` keys are present, they are used to configure the strategy. -- `ViewModel`. In this case, no service is registered; the `ViewModel` is simply retrieved from the +* `ViewModel`. In this case, no service is registered; the `ViewModel` is simply retrieved from the `MvcEvent` and injected with the layout template name. The `ViewManager` also creates several other listeners, but does not expose them as services; these