Merge pull request #68 from froschdesign/hotfix/docs/60

[Docs] Fixes bullet lists - See #60

Author: weierophinney

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.

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.
@@ -172,15 +172,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:
@@ -206,13 +206,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.
@@ -270,22 +270,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`,

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`

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)
 
@@ -313,7 +312,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:
 
@@ -381,9 +380,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.
 
@@ -429,11 +428,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.
 
@@ -487,9 +486,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: