The life cycle _php instance of the request (request) to learn laravel with me

Overview

When using tools in the real world, if you understand how the tools work, you'll be more confident when you use them. So is application development. When you understand how a development tool works, it becomes more comfortable to use. The goal of this document is to provide a high-level overview that will give you a better grasp of how the Laravel framework works. With a better understanding of the entire framework, the components and functionality of the framework are no longer so cryptic, and it is more handy to develop applications. This document contains a high-level overview of the request lifecycle, as well as relevant content for startup files and application events.

If you can't immediately understand all the terms, don't lose heart, you can have a general grasp, and continue to accumulate and digest knowledge while reading the other chapters of the document.

The life cycle of the request

All requests sent to the application are processed through the public/index.php script. If you are using the Apache server, the. htaccess file contained in Laravel will process all requests and pass them to index.php. This is the beginning of the entire process of Laravel from accepting client requests to returning responses to clients. A general understanding of the Laravel boot process (bootstrap process) will help to understand the framework, which we may wish to discuss first.

So far, the most important concept you need to learn the Laravel boot process is the service provider. Open the app/config/app.php configuration file and find the providers array, and you will find a list of service providers. These providers serve as the primary boot mechanism for laravel. Before we dive into the service provider, let's go back to Index.php's discussion. When a request enters the index.php file, the bootstrap/start.php file is loaded. This file creates a Laravel Application object that serves as the framework's IoC container.

When the Application object is created, the framework sets some path information and runs the environment detection. It then executes the boot script located inside the Laravel source code, and sets the time zone, error report, and other information according to your configuration file. In addition to configuring these trivial configuration options, the script does a very important thing: Register all the service providers configured for the application.

A simple service provider contains only one method: register. When an Application object registers a service provider through its own register method, the service provider's register method is invoked. This method is used by the service provider to register something with the IoC container. Essentially, each service provider binds one or more closures to the container, and you can access the services that are bound to the application through these closures. For example, Queueserviceprovider registers multiple closures to use multiple classes related to queues. Of course, the service provider is not limited to registering content with the IOC container, but it can be used for any boot-nature task. The service provider can register event listeners, view synthesizers, artisan commands, and so on.

After registering all the service providers, the files under App/start are loaded. Finally, the app/routes.php file is loaded. Once the routes.php file is loaded, the Request object is sent to the Application object, which is then distributed to a route.

Let's summarize:

Request to enter public/index.php file.
bootstrap/start.php file creates an Application object and detects the environment.
The internal framework/start.php file configures the related settings and loads the service provider.
Loads the files in the application App/start directory.
Loads the application's app/routes.php file.
Sends the Request object to the Application object, and the Application object returns a Response object.
Sends the Response object back to the client.
You should already have mastered how the Laravel application handles the requests sent. Let's take a look at the startup files below.

Startup file

The application's startup files are stored in the App/start directory. By default, this directory contains three files: global.php, local.php, and artisan.php files. For more information about artisan.php, refer to the Documentation Artisan command line.

The global.php startup file defaults to include some basic items, such as logging registrations and loading app/filters.php files. However, you can do anything you want in the file. In any environment, it will be automatically included in the _ each _request. The local.php file is only executed in the local environment. For more information about the environment, see the documentation configuration.

Of course, if you have other environments in addition to the local environment, you can also create startup files for these environments. These files will be automatically included when the application is running in the environment. If you configure a development environment in the bootstrap/start.php file, you can create a app/start/development.php file in which any request to enter the application will be included.

What is stored in the boot file?

Startup files are primarily used to store any "boot" code. For example, you can register a view synthesizer in a startup file, configure log information, or make some PHP settings. Exactly what you do depends on you. Of course, throwing all the boot code into the boot file makes the startup files cluttered. For large applications, or startup files are too cluttered, consider moving some of the boot code into the service provider.

Application Events

You can also register before, after, finish, and shutdown application events to do something before or after processing the request:

Registering Application Events

Copy Code code as follows:

App::before (function ($request)
{
//
});

App::after (function ($request, $response)
{
//
});

The listeners of these events run before each request to the application is processed (before) or later (after). You can use these events to set the global filter (filter) or to uniformly modify the response (response) that is sent back to the client. You can register these events in a startup file or in a service provider.

The finish event is triggered when the response from the application is sent to the client. This event is appropriate for the final finishing work required to handle the application. The Shutdown event is immediately triggered when all finish listeners have finished executing, and this is the last chance if you want to do something before the end of the script. In most cases, however, you do not need to use these events.