thinkPHP5.0 Framework Application Request life cycle analysis

This article mainly introduces the THINKPHP5.0 framework application request life cycle, the detailed analysis of thinkPHP5.0 framework application request life cycle involved in the implementation process, the need for friends can refer to the following

This article describes the thinkPHP5.0 framework application request life cycle. Share to everyone for your reference, as follows:

This article provides an overview of the lifecycle of ThinkPHP5.0 application requests, so that developers can understand the entire implementation process.

1. Entry file

User-initiated requests go through the application's portal file, usually the public/index.php file. Of course, you can also change or add a new entry file.

Usually the entry file code is relatively simple, a common entry file code is as follows:

Application Portal File//define project Path define (' App_path ', __dir__. '/.. /application/');//load frame boot file require __dir__. '/.. /thinkphp/start.php ';

General portal file has defined some constants, supported constants please refer to the following sections or appendix.

In general, we do not recommend adding too much code to the application portal file, especially code that is related to business logic.

2. Boot file

Next is the boot file that executes the framework, and the start.php file is the default boot file for the system. In the boot file, the following actions are performed:

① load system constant definition;
② load environment variable definition file;
③ registration automatic loading mechanism;
④ registration error and exception handling mechanism;
⑤ loading the custom configuration file;
⑥ implementation of the application;

If you change the default boot file in your app's portal file, the above execution process may follow a change.

3, registration automatic loading

The system calls the Loader::register () method to register for automatic loading, and after this is done, all conforming class libraries, including the third-party class library that the composer relies on for loading, are automatically loaded.

The automatic loading of the system consists of two parts:

Automatic loading method of ① registration system \think\loader::autoload
② Registration System Namespace definition
③ Load Class Library mapping file (if present)
④ If a composer installation exists, the registration composer automatically loads
⑤ Registering Extend Extensions directory

The automatic load detection sequence for a class library is:

① whether class library mappings are defined;
②PSR-4 Automatic load detection;
③psr-0 Automatic load detection;

As you can see, the way to define class library mappings is most efficient.

4. Registration error and abnormal mechanism

Executes the Error::register () registration error and exception handling mechanism.

Consists of three parts:

① Application Shutdown Method: think\Error::appShutdown
② Error handling method: think\Error::appError
③ Exception Handling method:think\Error::appException

The registration application Shutdown method is designed to facilitate the interception of some system errors.

During the lifetime of the entire application request, if an exception or critical error is thrown, it causes the application to end prematurely and responds to output exceptions and error messages.

5. Application initialization

The first step in performing an application is to initialize the app, including:

Load the application (public) configuration;
Load the application state configuration;
Load alias definition;
Load behavior definition;
Load public (function) files;
Load extension configuration file (defined by extra_config_list);
Load extension function file (defined by extra_file_list);
Set the default time zone;
Loading system language packs;

6. URL Access detection

When the application initialization is complete, URL access detection is performed, including path_info detection and URL suffix detection.

5.0 URL Access must be a URL address for the Path_info method (including the Compatible method), for example:

Http://serverName/index.php/index/index/hello/val/value

So, if your environment can only support URL parameter access in normal ways, you must use the

Http://serverName/index.php?s=/index/index/hello&val=value

If the portal file is accessed below the command line, the

$php index.php index/index/hello/val/value...

You cannot continue until you have obtained the normal $_SERVER['PATH_INFO'] parameters.

7. Route detection

If the url_route_on parameter is turned on, the URL's route detection will be performed first.

If a matching route is detected, the routing address that is defined is registered to the appropriate URL schedule.

The routing address of 5.0 supports the following methods:

Routing to modules/controllers/operations;
Route to an external redirect address;
Routing to the Controller method;
Routed to the closure function;
Methods for routing to classes;

Routing addresses may be affected by domain binding.

The default module/controller/operation analysis is identified if the route is closed or the route detection is invalid.

If the application scheduling method is specified when the application is initialized, route detection is optional.

You can use it \think\App::dispatch() for app scheduling.

8. Distribution Request

After URL detection and route detection are complete, the router distributes the request to the corresponding routing address, which is one of the most important aspects of the application request's life cycle.

In this step, you complete the application's business logic and return the data.

It is recommended that return data be used uniformly instead of the echo output, and do not perform exit interrupts, if not necessary.

The data from the direct echo output will not be able to automatically convert the response output convenience.

The following is the system-supported distribution request mechanism, which can be selected as appropriate:

module/Controller/operation

This is the default distribution request mechanism, the system according to the URL or routing address to determine the current request of the module, controller and operation name, and automatically call the appropriate access controller class, to perform the operation of the corresponding method.

Under this mechanism, the current module is judged first, and the module is initialized (similar to the application's initialization operation), and the configuration parameters of the module override the application's not yet valid configuration parameters.

Support for module mappings, URL parameters binding to methods, and operations binding to classes are some of the features.

Controller method

Similar to the previous one, there is simply no need to judge the module, controller, and operation to directly distribute the request to a specified controller class, so there is no initialization of the module.

External redirection

You can distribute the request directly to an external redirect address that supports specifying the redirect code, which defaults to 301 redirects.

Closure function

When routing address definition, we can use the closure function directly to accomplish some relatively simple logic operation and output.

Methods of the class

In addition to the methods above, the method of distributing requests to classes is supported, including:
static method:

' Blog/:id ' = ' \org\util\blog::read '

Methods of the class:

' Blog/:id ' = ' \app\index\controller\blog@read '

9. Response output

All operation methods of the controller are returned instead of direct output, and the method is called to Response::send output the data returned by the final application to the page or client, and is automatically converted into default_return_type the format of the parameter configuration. Therefore, the data output of the application execution only needs to return a normal PHP data.

10. End of application

In fact, after the application data response output, the application does not really end, the system will be in the application of output or interrupt after the log save write operations.

The log of the system includes the user debug output and the system auto-generated log, and unification will be written at the end of the application.

The write operation of the log is affected by the log initialization.