Zend's MVC mechanism usage analysis (2)_PHP tutorial

Following the above article

Post the code

setRequest($request) This is to determine whether the request is inherited from Zend_Controller_Request_Abstract. If so, assign the value of front's _request to it.

Here you need to understand what Zend_Controller_Request_Abstract is. It is an abstract class that abstracts all requests. Zend has provided two implementation classes, Zend_Controller_Request_Http and Zend_Controller_Request_Simple. Generally, when we build servers, we use http requests, so if your project needs to inherit again, it usually directly inherits Zend_Controller_Request_Http.

In Zend_controller_Request_Http, the usual Http options such as getQuery, getCookie, getRequestUri, getBasePath, getParams, getHeader, etc. that we often use are already available.

Continue to talk about its base class Zend_Controller_Request_Abstract. The methods of this class include:

Back to code

$front->setRequest(new Zend_Controller_Request_Http()); The constructor of Zend_Controller_Request_Http is called here. When the constructor is called for the first time, it is $this->setRequestUri(); many of the setRequestUri are direct Use the data in the PHP global variable $_SERVER to get the requestUri.

What you can learn from setRequestUri is how to obtain requestUri in different servers (especially the different variable combinations in $SERVER in IIS have different meanings), such as http://172.23.11.160/usvn/item/ usvn_test This url, its requestUri is /usvn/item/usvn_test

$front->throwExceptions(true); Set the internal _throwExceptions flag to true;

$front->setbaseUrl("/usvn") does two things. First, it sets the internal _baseUrl attribute of front. Second, it calls setBaseUrl of Request, which also sets the internal _baseUrl attribute of Zend_Controller_Request_Http.

$router = new Zend_Controller_Router_Rewrite();

$routes_config = new USVN_Config_Ini(USVN_ROUTES_CONFIG_FILE, USVN_CONFIG_SECTION);

$router->addConfig($routes_config, 'routes');

$front->setRouter($router);

The following three lines directly state that they actually use Zend’s Router module to use the configuration file. The router uses setRouter and is placed in the front.

Last sentence

$front->dispatch();

This function is also the most core function.

This function first registers a plug-in Zend_Controller_Plugin_ErrorHandler with an index of 100 and puts the plug-in order at the end.

The second step stores a Helper, Zend_Controller_Action_Helper_ViewRenderer, with an index of -80

Request is instantiated below, and request is a Zend_Controller_Request_Http type. And set the baseUrl of the request to the _baseUrl set previously, which is "/usvn/item/usvn_test"

Then the response is instantiated, and the response is a Zend_Controller_Response_Http();

The following uses plugins to set Request and Response. First, the setRequest function of Zend_Controller_Plugin_Broker is actually called. This function loops through all the plugins managed by the broker and calls the setRequest($request) function of the plugin (if any).

Next, initialize the router and set the parameters of the router. The router has been set previously, which is the Zend_Controller_Router_Rewrite type

Initialize the dispatcher dispatcher. We see the dispatcher for the first time, the Zend_Controller_Dispatcher_Standard class. Distributors will be discussed later.

The following process:

Call the routeStartup of the plug-in to process the request

Call the router’s route to handle the request

Call the plugin’s routeShutdown to process the request

Call the dispatchLoopStartup of the plug-in to process the request

Enter the cycle distribution process

Call the preDispatch of the plug-in to process the request

Call dispatcher’s dispatch to process request and response

Call the plug-in’s postDispatch to process the request

Get out of the loop distribution process

Call the plugin’s dispatchLoopShutdown to process the request

Send response