ZendFramework tutorial-front-end controller Zend_Controller_Front usage-php instance

This article mainly introduces the Zend_Controller_Front usage of the front-end controller in the ZendFramework tutorial, and analyzes in detail the functions of the front-end controller Zend_Controller_Front, usage methods and related precautions, for more information about Zend Framework, see the Zend_Controller_Front command. We will share this with you for your reference. The details are as follows:

Main functions

The core mechanism implemented by ZendFramework MVC is through the Zend_Controller_Front front-end controller, which is used to initialize the request environment, process requests, route distribution, and complete response operations. Zend_Controller_Front adopts the singleton mode, therefore, an application only has one front-end controller. If you want the front-end controller to provide some special functions, You can inherit the Zend_Controller_Front custom front-end controller.

Main Method

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 action controller class files are stored. The parameter can be a path string or an associated array.

For example:

// The path is relative to the/application directory of the application. // string $ front-> setControllerDirectory ('.. /application/controllers '); // associate the 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 addControllerDirectory () is used without the module name, a directory will be set for the default module-if the directory has been set, it will be overwritten.

You can use getControllerDirectory () to obtain the current settings of the controller directory. It returns a module/directory pair associated 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 one "controllers" word directory and "views" sub-directory and other application sub-directories.

AddModuleDirectory () allows you to pass a directory name that contains one or more module directories. Then scan and add them as the controller directory to the front-end controller.

Then, if you want to determine the path of a specific module or the current module, call getModuleDirectory () and pass the module name to obtain the Module Directory.

Dispatch ()

Dispatch (Zend_Controller_Request_Abstract $ request = null, Zend_Controller_Response_Abstract $ response = null) to complete the most heavy work of the front-end controller. This method has optional parameter request objects and/or response objects, allowing developers to customize each input object.

If no request or response object is received, dispatch () checks the previously registered objects and uses them. If no result is found, the default object version is created (both of them use HTTP objects by default ).

Similarly, dispatch () first checks the registered routers and dispatcher objects. If not, instantiate their default versions.

The distribution process has three different events: Routing, Dispatching, and Response)

A route occurs only once. When dispatch () is called, the value in the request object is used. Distribution occurs in a loop. A request may indicate distributing multiple actions, or the Controller or plug-in may reset the request object to force distributing additional actions. After all the operations are completed, the front-end controller returns the response object.

Run ()

Zend_Controller_Front: run ($ path) is a static method with only one parameter, that is, the path to the directory containing the controller. It first obtains the front-end controller instance through getInstance (), then registers the input path through setControllerDirectory (), and finally delivers the information.

Basically, if you do not need to customize the front-end controller environment, run () is a convenient method to establish the front-end controller environment.

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

Environment accessors

In addition to the methods listed above, there are also many accessors that can affect the front-end controller environment-and thus affect the class environment of the front-end controller proxy (delegate.

The resetInstance () method clears all current settings. It is mainly used for testing. However, it is useful to link several front-end controllers (but it can also be used for instances where you wish to chain together multiple front controllers ).

(Set | get) The DefaultControllerName () method can specify another name for the default controller (otherwise, use 'index') and obtain the current value. They use the proxy distributor.

(Set | get) The DefaultAction () method can specify another name for the default action (otherwise, use 'index') and obtain the current value. They use the proxy distributor.

(Set | get) Request () method specifies the Request class or object used in the distribution process, and obtains the current Request object. When setting a request object, you can input a name for the request class. This method loads the class file and creates an instance.

The (set | get) Router () method specifies the Router class or object used in the distribution process and obtains the current object. When setting a vro, you can enter the name of a vro class. This method loads the class file and creates an instance.

When obtaining a vro object, first check whether one exists. If not, create a default vroreinstance (rewrite vro ).

The (set | get) BaseUrl () method specifies the base address (base URL) of strip when a route request is sent, and obtains the current value. This value is provided to the router on the premise of routing.

(Set | get) the Dispatcher () method specifies the distributor class or object used in the distribution process and obtains the current object. When setting a distributor object, you can pass in the name of a distributor class. This method loads the class file and creates an instance.

When obtaining a distributor object, first check whether one exists. If not, a default distributor instance is created.

The (set | get) Response () method specifies the Response class or object used in the distribution process. The current object has been obtained. When setting a response object, you can input a response class name. This method loads the class file and creates an instance.

The registerPlugin (Zend_Controller_Plugin_Abstract $ plugin, $ stackIndex = null) method allows you to register a plug-in object. Set the optional parameter $ stackIndex to display the execution sequence of the plug-in.

The unregisterPlugin ($ plugin) method removes the plug-in object. $ Plugin can be a plug-in object or a string that represents the removal of the plug-in class.

The throwExceptions ($ flag) method is used to enable or disable the ability to throw exceptions during the distribution process. By default, exceptions are thrown and placed in the response object. If throwExceptions () is enabled, this row will be overwritten.

The returnResponse ($ flag) method notifies the front-end Controller whether to return the request object (true) from dispatch (). Otherwise, the system automatically sends the response object (false -). By default, the response object is automatically sent (by calling Zend_Controller_Response_Abstract: sendResponse (); enabling returnResponse () will overwrite this line.

The reason for returning the response object includes checking for exceptions before sending the response, recording various attributes of the response (such as the message header), and so on.

Front-end Controller Parameters

The introduction mentioned that front-end controllers can be used as registries for various controller components. It does this through a "param" Family method. These methods allow the front-end controller to register any type of data-objects and variables, which can be obtained at any time in the distribution chain. These variables are passed to the router, distributor, and Action controller. These methods include:

The setParam ($ name, $ value) method sets a single parameter $ name with a value of $ value.
The setParams (array $ params) method sets multiple parameters at a time by associating arrays.
The getParam ($ name) method obtains a single parameter using the $ name identifier.
The getParams () method obtains the entire parameter list at a time.
The clearParams () method can empty a parameter (input a single string identifier), clear multiple parameters (input a string identifier array), and clear the entire parameter stack (without passing in parameters ).

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

Usedefacontrocontrolleralways is used to prompt the distributor to use the default controller of the default module when it encounters a request that cannot be distributed. This is disabled by default.

Read the MVC exceptions that may be encountered to obtain more detailed information on using this setting.

DisableOutputBuffering is used to prompt that the is used to hint to distributor does not use the output buffer to capture the output produced by the action controller. By default, the distributor captures any output and appends it to the body content of the response object.

NoViewRenderer is used to disable ViewRenderer. If this parameter is set to true, this assistant can be disabled.

NoErrorHandler is used to disable the error processor plug-in. If this parameter is set to true, the plug-in can be disabled.

Custom front-end Controller

To inherit the front-end controller, at least the getInstance () method must be overwritten:

class My_Controller_Front extends Zend_Controller_Front{  public static function getInstance()  {    if (null === self::$_instance) {      self::$_instance = new self();    }    return self::$_instance;  }}

Overwrite getInstance () to ensure that Zend_Controller_Front: getInstance () will be called later to return the subclass instance instead of the Zend_Controller_Front instance, which is very useful for some replaceable routers and view assistants.

Generally, you do not need to inherit the front-end controller unless you need to add new functions (such as a plug-in auto loader or a method to specify the action assistant path ). You may want to modify 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. Therefore, Zend_Controller_Front usually does not exist for applications. To use the functions provided by Zend_Controller_Front, use Zend_Controller_Front: getInstance (); to obtain the instance.