Zend Framework Tutorial The front-end controller Zend_controller_front usage _php example

Source: Internet
Author: User
Tags zend zend framework

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

Main function

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

Main methods

GetInstance ()

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

For example:

The path is relative to the applied/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, you will set the directory for the default module-if the directory is set, overwrite it.

The current setting of the controller directory can be obtained by getcontrollerdirectory (), and 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 separate components, called "modules."

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

Addmoduledirectory () lets you pass a directory name that contains one or more module directories. They are then scanned and added to the front-end 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 heaviest work of the front-end controller. The method has optional parameter request objects and/or response objects that allow developers to customize objects for each pass in.

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

Similarly, dispatch () first checks the registered routers (router) and distributor (dispatcher) objects and instantiates their default versions if no discovery is made.

There are three different events in the distribution process: Routing (Routing), distribution (dispatching), Response (Response)

Routing occurs only once and takes advantage of the value in the Request object when dispatch () is invoked. 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, forcing the distribution of additional actions. When all is done, the front-end controller returns the response object.

Run ()

Zend_controller_front::run ($path) is a static method with only one argument, or a path to the directory that contains the controller. It first obtains the front-end controller instance through getinstance (), and then registers the incoming path through Setcontrollerdirectory (), and finally distributes it.

Basically, if you don't require custom front-end controller environments, run () is a convenient way to build 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 environment of the front-end controller environment-and thus the class of the front-end controller agent (delegate).

The Resetinstance () method clears all current settings. It's mainly for testing, but it's also useful where you want to chain several front-end controllers (but it can also be used for instances where and 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 distributor.

(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 distributor.

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

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

When you get a router object, first check to see if there is one, and if not, create a default router instance (rewrite router).

(Set|get) The BaseURL () method specifies the base address (base URL) of the split (strip) when routing requests, and gets the current value. This value will be supplied to the router before routing.

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

When you get the Distributor object, first check to see if one exists, and if not, a default distributor instance will be created.

(Set|get) The Response () method specifies the response class or object used during the distribution process, and the current object is already fetched. When you set the response object, you can pass in the name of a response class that will load the class file and create the instance.

Registerplugin (zend_controller_plugin_abstract $plugin, $stackIndex = null) method allows you to register a plug-in object. The order in which plug-ins are executed by setting optional parameter $stackindex.

The Unregisterplugin ($plugin) method removes the plug-in object. $plugin can be a plug-in object or a string that represents 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, the exception is caused and placed in the response object, and opening throwexceptions () will overwrite the behavior.

The Returnresponse ($flag) method notifies the front-end controller whether the request object (TRUE) is returned from dispatch (), otherwise the Response object (false-) is automatically sent. By default, the response object is sent automatically (by calling Zend_controller_response_abstract::sendresponse ()), and opening returnresponse () overrides the behavior.

The reason for returning the response object is that you want to check for exceptions before sending the response, record the various properties of the response (such as message headers), and so on.

Front Controller parameters

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

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

There are several predefined parameters to set up, and they have special uses in the distribution chain:

Usedefaultcontrolleralways uses the default controller of the default module when it prompts the Distributor to encounter a request that cannot be distributed. This is turned off by default.

Read the MVC exception you might encounter get more detailed information about using this setting.

Disableoutputbuffering is used to hint that the is used to hint the to distributor does not use output buffering to capture output generated by an 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. Set this argument to true to disable the assistant.

Noerrorhandler is used to disable the error processor plug-in. Set this argument to True to disable the plug-in.

Customizing the Front-End Controller

To inherit the front-end controller, you need to overwrite the getinstance () method at least:

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 () guarantees that subsequent calls to Zend_controller_front::getinstance () will return an instance of the subclass rather than the Zend_controller_front instance. This is useful for some replaceable routers and view assistants.

It is not usually necessary to inherit the front-end controller unless you need to add new functionality (for example, a plug-in loader, or a method to specify the action assistant path). The place you want to change may include modifying the way the controller directory is stored, using the default router, and the Distributor.

The default front-end controller provided by Zendframewrok is enough for us to use, through the bootstrap function, there is absolutely no need to manually write code to change the default mechanism of Zend_controller_front. So in general, Zend_controller_front is not available for applications. If you need to use the functionality provided by Zend_controller_front, get the instance by Zend_controller_front::getinstance ();

More interested in Zend related content readers can view the site topics: "The introduction of the Zend Framework frame", "PHP Excellent Development Framework Summary", "Yii framework Introduction and common skills Summary", "thinkphp Introductory Course", "PHP object-oriented Programming Program , "Php+mysql Database operation Introduction Tutorial" and "PHP common database Operation Skills Summary"

I hope this article will help you with the PHP program design.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.