Usage of Zend_controller_front in the Zend framework

This article mainly introduces the Zend Framework tutorial of the front-end controller Zend_controller_front usage, detailed analysis of the front-end controller Zend_controller_front function, the use of methods and related considerations, A friend you need can refer to the following

This example describes the Zend_controller_front usage of the front-end controller for the Zend Framework tutorial. Share to everyone for your reference, as follows:

Key Features

The core mechanism of Zendframework's MVC implementation is through the Zend_controller_front front-end controller, which is used to initialize the request environment, process requests, route distribution, complete the response operation, Zend_controller_front the singleton mode, So one application has only one front-end controller. If you need a front-end controller to provide some special features, you can inherit the Zend_controller_front custom front controller.

Main methods

GetInstance ()

Used to obtain the 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 location where the action controller class file is stored. Parameters can be either a path string or an associative array.

For example:

The path is relative to the app's/application Directory///String $front->setcontrollerdirectory ('.. /application/controllers ');//associative array $front->setcontrollerdirectory (  ' 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 has been set, it will be overwritten.

The current setting of the controller directory can be obtained through getcontrollerdirectory (); it returns 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 separate components called "modules".

Each module is located in its own directory and is the same as the directory structure of the default module-for example, it has at least one "controllers" and "views" subdirectory and other application subdirectories.

Addmoduledirectory () lets you pass a directory name that contains one or more module catalogs. They are then scanned and added to the front controller as the controller directory.

Then, if you want to determine the specific module or current module path, call Getmoduledirectory () and optionally pass the module name to get the module directory.

Dispatch ()

Dispatch (Zend_controller_request_abstract $request = null, zend_controller_response_abstract $response = null) Complete the most onerous work of the front controller. The method has an optional parameter request object and/or response object that allows the developer to pass in the custom object for each one.

If no request or response object is passed in, dispatch () checks the previously registered objects and uses them, creating a default version of the object if not found (all two of them use HTTP objects by default).

Similarly, dispatch () checks the registered router (router) and dispatcher (dispatcher) objects first, and instantiates their default versions if they are not found.

The distribution process has three different events: Routing (Routing), distribution (dispatching), Response (Response)

The route occurs only once when dispatch () is called to take advantage of the value in the Request object. The 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 to force the distribution of additional actions. When all is done, the front 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 obtains the front-end controller instance through getinstance (), then registers the incoming path through Setcontrollerdirectory (), and finally distributes it.

Basically, if you do not require a custom front-end controller environment, run () is a convenient way to create a front-end controller environment.

Zend_controller_front::run ('.. /application/controllers ');

Environment accessor methods

In addition to the methods listed above, there are many accessor methods that can affect the environment of the front-end controller environment-and hence the class of the Front Controller agent (delegate).

The Resetinstance () method clears all current settings. Primarily used for testing, however, it is also useful in places where you want to chain several front-end controllers (but it can also is used for instances where you wish to chain together multiple front con trollers).

(Set|get) The Defaultcontrollername () method can specify a different name for the default controller (otherwise use ' index ') and get the current value. They will proxy the dispatcher.

(Set|get) The DefaultAction () method can specify a different name for the default action (otherwise use ' index ') and get the current value. They will proxy the dispatcher.

(Set|get) The request () method specifies the requested class or object used during distribution, and gets the current request object. When you set the Request object, you can pass in the name of a request class that loads the class file and creates the instance.

(Set|get) The Router () method specifies the router class or object used during distribution, and gets the current object. When you set up a router, you can pass in the name of a router class that loads the class file and creates an instance.

When getting the Router object, first check if there is one, and if not, create the default router instance (rewrite router).

(Set|get) The BASEURL () method specifies the base address (base URL) at which the route request is stripped (strip), and gets the current value. This value will be provided to the router before routing.

(Set|get) The Dispatcher () method specifies the Dispatcher class or object used during distribution, and gets the current object. When you set the Dispatcher object, you can pass in the name of a dispatcher class that loads the class file and creates the instance.

When you get the Dispatcher object, first check to see if there is an existing one, and if not, a default dispatcher instance is created.

(Set|get) The Response () method specifies the response class or object used during distribution, and the current object has already been acquired. When you set a response object, you can pass in the name of a response class that loads the class file and creates the instance.

Registerplugin (zend_controller_plugin_abstract $plugin, $stackIndex = null) method allows you to register a plug-in object. By setting optional parameter $stackindex, the order in which the plug-in executes.

The Unregisterplugin ($plugin) method removes the plug-in object. $plugin can be a plug-in object or a string representing the removal of a plug-in class.

The Throwexceptions ($flag) method is used to turn on or off the ability to throw exceptions during distribution. By default, exceptions are caused and placed in the response object; opening throwexceptions () overrides 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-) is sent automatically. By default, the response object is sent automatically (by calling Zend_controller_response_abstract::sendresponse ()); turning on Returnresponse () overrides this behavior.

The reasons for returning a response object include wanting to check for exceptions before sending a response, logging various properties of the response (such as message headers), and so on.

Front Controller parameters

The introduction mentioned that the front controller can be used as a registry for various controller components. It does this by means of a "param" family. These methods allow the front-end controller to register any type of data-objects and variables-that can be obtained at any time in the distribution chain. These variables are passed to the router, the dispatcher, and the action controller. These methods include:

The SetParam ($name, $value) method sets the value to a single parameter $name of $value.
The SetParams (array $params) method sets multiple parameters at once through an associative array.
The GetParam ($name) method gets a single argument through the $name identifier.
The Getparams () method gets the entire list of parameters at once.
The Clearparams () method empties a parameter (passing in a single string identifier), empties multiple parameters (passing in an array of string identifiers), and empties the entire argument stack (without passing in parameters).

There are several predefined parameters that can be set, and they have special uses in the distribution chain:

The usedefaultcontrolleralways is used to prompt the Distributor to use the default controller when it encounters a request that cannot be distributed. This is off by default.

Read the MVC exceptions you might encounter to get more detailed information on using this setting.

Disableoutputbuffering is used to indicate that the is used to hint-to dispatcher does not use output buffering to capture output generated by an action controller. By default, the dispatcher captures any output and appends the body content to the response object.

Noviewrenderer is used to disable Viewrenderer. Set this parameter to true to disable the assistant.

The Noerrorhandler is used to disable the error handler plug-in. Set this parameter to True to disable the plug-in.

Customizing the front-end controller

To inherit a front-end controller, you need to overwrite at least 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;}  }

overwriting getinstance () guarantees that subsequent calls to Zend_controller_front::getinstance () return an instance of the subclass, not the Zend_controller_front instance, This is useful for some replaceable routers and view assistants.

You typically do not need to inherit the front-end controller unless you need to add new functionality (for example, a plug-in autoloader, or a method to specify the action helper path). Where you want to change may include modifying the way the controller directory is stored, the default router used, and the distributor.

The default front-end controller provided by Zendframewrok is enough for us to use, with the bootstrap feature, there is absolutely no need to manually write code to change the Zend_controller_front default mechanism. So the zend_controller_front usually does not exist for the application. If you need to use the functionality provided by Zend_controller_front, go through Zend_controller_front::getinstance () and get the instance.

The above is the whole content of this article, I hope that everyone's learning has helped, more relevant content please pay attention to topic.alibabacloud.com!