This article describes the usage of Zend_Controller_Front, the front-end controller, before the Zend Framework tutorial. Share it for your reference, as follows:
Main functions
The core mechanism of ZendFramework's MVC implementation is to initialize the request environment, process requests, route distribution, and complete response operations through the Zend_Controller_Front front-end controller. The singleton mode is adopted by Zend_Controller_Front, so one application has only one front-end controller. If you need the front-end controller to provide some special features, you can inherit the Zend_Controller_Front custom front-end controller.
Main methods
getInstance()
Used to obtain front-end controller instance. The only way to create a front-end controller object.
$front = Zend_Controller_Front::getInstance();
setControllerDirectory() and addControllerDirectory()
setControllerDirectory() sets the storage location of the action controller class file. The parameters can be path strings or associative arrays.
For example:
//The path is relative to the application directory// String$front->setControllerDirectory('../application/controllers');
// Associate array$front->setControllerDirectory(array(
'default' => '../application/controllers',
'blog' => '../modules/blog/controllers',
'news' => '../modules/news/controllers',
));
// Add a 'foo' module directory:
$front->addControllerDirectory('../modules/foo/controllers', 'foo');
Note: If you use addControllerDirectory() without the module name, the directory will be set for the default module - if the directory is set, it will be overwritten.
The current settings of the controller directory can be obtained through getControllerDirectory(); it will return a module/directory pair associative array.
addModuleDirectory() and getModuleDirectory()
One function of the front-end controller is that you can define a module directory structure to create independent components called "modules".
Each module is located in its own directory and has the same directory structure as the default module - for example, it has at least a "controllers" word directory and a "views" subdirectory, and other application subdirectories.
addModuleDirectory() lets you pass a directory name that contains one or more module directories. Then scan and add them as controller directories to the front-end controller.
Then, if you want to determine the specific module or the current module path, call getModuleDirectory(), optionally passing the module name to get the module directory.
dispatch()
dispatch(Zend_Controller_Request_Abstract $request = null, Zend_Controller_Response_Abstract $response = null) completes the heaviest work of the front-end controller. This method comes with optional parameter request objects and/or response objects, allowing developers to pass in custom objects for each incoming.
If no request or response object is passed in, dispatch() will check the previously registered object and use it, and create the default object version if it is not found (both of them use HTTP objects by default).
Similarly, dispatch() checks registered router and dispatcher objects first, and instantiates their default versions if not found.
There are three different events in the distribution process: Routing, Dispatching, and Response
The routing occurs only once, and the value in the request object is used when dispatch() is called. Distribution occurs in a loop; the request may indicate that multiple actions are distributed, or the controller or plug-in may reset the request object, forcing the additional actions to be distributed. After all is done, the front-end controller returns the response object.
run()
Zend_Controller_Front::run($path) is a static method with only one parameter, which is the path to the directory containing the controller. It first gets the front-end controller instance through getInstance(), then registers the incoming path through setControllerDirectory(), and finally distributes it.
Basically, if you do not require customizing the front-end controller environment, run() is a very convenient way to establish a front-end controller environment.
Zend_Controller_Front::run('../application/controllers');
Environment accessor method
In addition to the methods listed above, there are many accessor methods that can affect the front-end controller environment - and thus also affect the environment of the class of the front-end controller agent (delegate).
The resetInstance() method clears all current settings. It is mainly used for testing, but it can also be used for instances where you wish to chain together multiple front controllers.
(set|get)DefaultControllerName() method can specify another name for the default controller (otherwise use 'index') and get the current value. They will proxy the distributor.
(set|get)DefaultAction() method can specify another name for the default action (otherwise use 'index'), and get the current value. They will proxy the distributor.
(set|get)Request() method specifies the request class or object used during the distribution process and obtains the current request object. When setting up a request object, you can pass in the name of a request class, which will load the class file and create an instance.
(set|get)Router() method specifies the router class or object used during the distribution process and obtains the current object. When setting up a router, you can pass in the name of a router class, which will load the class file and create an instance.
When obtaining the router object, first check whether there is already one. If not, create the default router instance (rewrite router).
(set|get)BaseUrl() method specifies the base address (base URL) of stripping during routing request and obtaining the current value. This value will be provided to the router before routing.
(set|get)Dispatcher() method specifies the distributor class or object used during the distribution process and obtains the current object. When setting a distributor object, you can pass in the name of a distributor class, which will load the class file and create an instance.
When getting the distributor object, first check whether there is already an existing one. If not, a default distributor instance will be created.
(set|get)Response() method specifies the response class or object used during the distribution process, and the current object has been obtained. When setting the response object, you can pass in the name of a response class, which will load the class file and create an instance.
The registerPlugin(Zend_Controller_Plugin_Abstract $plugin, $stackIndex = null) method allows registration of a plug-in object. The order in which the plugin is executed is set by setting the optional parameter $stackIndex.
The unregisterPlugin($plugin) method removes the plugin object. $plugin can be a plugin object or a string representing the removal of the plugin class.
The throwExceptions($flag) method is used to enable or close the ability to throw exceptions during distribution. By default, exceptions are caused and placed in the response object; turning on throwExceptions() will override this behavior.
The returnResponse($flag) method notifies the front-end controller whether to return the request object (true) from dispatch(), otherwise the response object (false—) will be automatically sent. By default, the response object is automatically sent (by calling Zend_Controller_Response_Abstract::sendResponse()); turning on returnResponse() will override this behavior.
Reasons for returning a response object include wanting to check for exceptions before sending a response, recording various properties of the response (such as message headers), and so on.
Front-end controller parameters
The introduction mentioned that front-end controllers can be used as registry for various controller components. It does this through a "param" family method. These methods allow the registration of any type of data—objects and variables—through the front-end controller, which can be retrieved at any time in the distribution chain. These variables are passed to the router, the distributor, and the action controller. These methods include:
The setParam($name, $value) method sets the single parameter $name with the value $value.
The setParams(array $params) method sets multiple parameters at once by associating the array.
The getParam($name) method obtains a single parameter through the $name identifier.
The getParams() method gets the entire parameter list at once.
The clearParams() method can clear one parameter (pass a single string identifier), clear multiple parameters (pass a string identifier array), and clear the entire parameter stack (no parameters passed in).
There are several predefined parameters to set, and they have special uses in the distribution chain:
useDefaultControllerAlways is used to prompt the distributor to use the default module's default controller when encountering requests that cannot be distributed. This is turned off by default.
Read MVC exceptions you may encounter to get more detailed information about using this setting.
disableOutputBuffering is used to prompt that the distributor does not use the output buffer to capture the output generated by the action controller. By default, the distributor captures any output and appends to the body content of the response object.
noViewRenderer is used to disable ViewRenderer. Setting this parameter to true can disable the assistant.
noErrorHandler is used to disable the error handler plugin. Setting this parameter to true can disable the plug-in.
Custom front-end controller
To inherit the front-end controller, at least you need to override the getInstance() method:
class My_Controller_Front extends Zend_Controller_Front
{
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
Overriding getInstance() ensures that later calling Zend_Controller_Front::getInstance() will return an instance of the subclass instead of the Zend_Controller_Front instance, which is very useful for some replaceable routers and view assistants.
Usually there is no need to inherit the front-end controller unless you need to add new features (such as a plug-in autoloader, or a method to specify the action assistant path). What you want to change may include modifying the storage method of the controller directory, the default router used, and the distributor.
The default front-end controller provided by ZendFramewrok is enough for us to use. Through the Bootstrap function, there is no need to manually write code to change the default mechanism of Zend_Controller_Front. So usually Zend_Controller_Front does not exist for the application. If you need to use the functions provided by Zend_Controller_Front, you can get the instance through Zend_Controller_Front::getInstance();.
For more information about Zend, please visit the special topic of this site:Zend FrameWork framework tutorial》、《Summary of excellent development framework for php》、《Yii framework introduction and common techniques summary》、《ThinkPHP Introduction Tutorial》、《PHP object-oriented programming tutorial》、《PHP+mysql database operation tutorial"and"Summary of common database operation techniques for php》
I hope this article will be helpful to everyone's PHP programming.