Previous Next



Accessing the Request and Response

When using ActionController or RestfulController, the request and response object are composed directly into the controller as soon as dispatch() is called. You may access them in the following ways:

// Using explicit accessor methods
$request  = $this->getRequest();
$response = $this->getResponse();

// Using direct property access
$request  = $this->request;
$response = $this->response;

Additionally, if your controller implements InjectApplicationEvent (as both ActionController and RestfulController do), you can access these objects from the attached MvcEvent:

$event    = $this->getEvent();
$request  = $event->getRequest();
$response = $event->getResponse();

The above can be useful when composing event listeners into your controller.

Accessing routing parameters

The parameters returned when routing completes are wrapped in a Zend\Mvc\Router\RouteMatch object. This object is detailed in the section on routing.

Within your controller, if you implement InjectApplicationEvent (as both ActionController and RestfulController do), you can access this object from the attached MvcEvent:

$event   = $this->getEvent();
$matches = $event->getRouteMatch();

Once you have the RouteMatch object, you can pull parameters from it.

Returning early

You can effectively short-circuit execution of the application at any point by returning a Response from your controller or any event. When such a value is discovered, it halts further execution of the event manager, bubbling up to the Application instance, where it is immediately returned.

As an example, the Redirect plugin returns a Response, which can be returned immediately so as to complete the request as quickly as possible. Other use cases might be for returning JSON or XML results from web service endpoints, returning "401 Forbidden" results, etc.


Registering module-specific listeners

Often you may want module-specific listeners. As an example, this would be a simple and effective way to introduce authorization, logging, or caching into your application.

Each Module class can have an optional init() method. Typically, you'll setup event listeners for you module here. The init() method is called for every module on every page request and should only be used for performing lightweight tasks such as registering event listeners.

The base Bootstrap class shipped with the framework has an EventManager associated with it, and once the locator and router instances are initialized, it triggers a "bootstrap" event, with "application" and "modules" parameters.

So, one way to accomplish module-specific listeners is to listen to that event, and register listeners at that time. As an example:

namespace SomeCustomModule;

use Zend\EventManager\StaticEventManager;

class Module
    public function init()
        // Remember to keep the init() method as lightweight as possible
        $events = StaticEventManager::getInstance();
        $events->attach('bootstrap', 'bootstrap', array($this, 'registerListeners'));

    public function registerListeners($e)
        $application = $e->getParam('application');
        $config      = $e->getParam('config');
        $view        = $application->getLocator()->get('view');

        $listeners   = new Listeners\ViewListener();

The above demonstrates several things. First, it shows registering a callback on the bootstrap's "bootstrap" event (within the init() method). Second, it demonstrates that listener, and how it can be used to register listeners with the application. It grabs the Application instance, as well as the module manager instance. From the Application, it is able to grab the attached locator, and from the Managar, it grabs configuration. These are then used to retrieve the view, configure some helpers, and then register a listener aggregate with the application event manager.

Previous Next