PluginsIntroductionThe controller architecture includes a plugin system that allows user code to be called when certain events occur in the controller process lifetime. The front controller uses a plugin broker as a registry for user plugins, and the plugin broker ensures that event methods are called on each plugin registered with the front controller. The event methods are defined in the abstract class Zend_Controller_Plugin_Abstract, from which user plugin classes inherit:
Writing PluginsIn order to write a plugin class, simply include and extend the abstract class Zend_Controller_Plugin_Abstract:
None of the methods of Zend_Controller_Plugin_Abstract are abstract, and this means that plugin classes are not forced to implement any of the available event methods listed above. Plugin writers may implement only those methods required by their particular needs. Zend_Controller_Plugin_Abstract also makes the request and response objects available to controller plugins via the getRequest() and getResponse() methods, respectively. Using PluginsPlugin classes are registered with Zend_Controller_Front::registerPlugin(), and may be registered at any time. The following snippet illustrates how a plugin may be used in the controller chain:
Assuming that no actions called emit any output, and only one action is called, the functionality of the above plugin would still create the following output:
Retrieving and Manipulating PluginsOn occasion, you may need to unregister or retrieve a plugin. The following methods of the front controller allow you to do so:
Plugins Included in the Standard DistributionZend Framework includes a plugin for error handling in its standard distribution. ActionStackThe ActionStack plugin allows you to manage a stack of requests, and operates as a postDispatch plugin. If a forward (i.e., a call to another action) is already detected in the current request object, it does nothing. However, if not, it checks its stack and pulls the topmost item off it and forwards to the action specified in that request. The stack is processed in LIFO order. You can retrieve the plugin from the front controller at any time using Zend_Controller_Front::getPlugin('Zend_Controller_Plugin_ActionStack'). Once you have the plugin object, there are a variety of mechanisms you can use to manipulate it.
An additional method, forward(), expects a request object, and sets the state of the current request object in the front controller to the state of the provided request object, and markes it as undispatched (forcing another iteration of the dispatch loop). Zend_Controller_Plugin_ErrorHandlerZend_Controller_Plugin_ErrorHandler provides a drop-in plugin for handling exceptions thrown by your application, including those resulting from missing controllers or actions; it is an alternative to the methods listed in the MVC Exceptions section. The primary targets of the plugin are:
In other words, the ErrorHandler plugin is designed to handle HTTP 404-type errors (page missing) and 500-type errors (internal error). It is not intended to catch exceptions raised in other plugins. By default, Zend_Controller_Plugin_ErrorHandler will forward to ErrorController::errorAction() in the default module. You may set alternate values for these by using the various accessors available to the plugin:
Additionally, you may pass an optional associative array to the constructor, which will then proxy to setErrorHandler(). Zend_Controller_Plugin_ErrorHandler registers a postDispatch() hook and checks for exceptions registered in the response object. If any are found, it attempts to forward to the registered error handler action. If an exception occurs dispatching the error handler, the plugin will tell the front controller to throw exceptions, and rethrow the last exception registered with the response object. Using the ErrorHandler as a 404 HandlerSince the ErrorHandler plugin captures not only application errors, but also errors in the controller chain arising from missing controller classes and/or action methods, it can be used as a 404 handler. To do so, you will need to have your error controller check the exception type. Exceptions captured are logged in an object registered in the request. To retrieve it, use Zend_Controller_Action::_getParam('error_handler'):
Once you have the error object, you can get the type via $errors->type;. It will be one of the following:
You can then test for either of the first three types, and, if so, indicate a 404 page:
Finally, you can retrieve the exception that triggered the error handler by grabbing the exception property of the error_handler object:
Handling Previously Rendered OutputIf you dispatch multiple actions in a request, or if your action makes multiple calls to render(), it's possible that the response object already has content stored within it. This can lead to rendering a mixture of expected content and error content. If you wish to render errors inline in such pages, no changes will be necessary. If you do not wish to render such content, you should clear the response body prior to rendering any views:
Plugin Usage ExamplesExample #1 Standard Usage Example #2 Setting a Different Error Handler
Example #3 Using Accessors
Error Controller ExampleIn order to use the Error Handler plugin, you need an error controller. Below is a simple example.
Zend_Controller_Plugin_PutHandlerZend_Controller_Plugin_PutHandler provides a drop-in plugin for marshalling PUT request bodies into request parameters, just like POST request bodies. It will inspect the request and, if PUT, will use parse_str to parse the raw PUT body into an array of params which is then set on the request. E.g.,
To receive the 'title' and 'body' params as regular request params, register the plugin: Then you can access the PUT body params by name from the request inside your controller:
|
|