Laravel 4.2 リクエストのライフサイクル

概論Overview

「現実の世界」でツールを使用する場合、その道具がどのように動作するかを理解しておいたほうが、自信が持てます。アプリケーションの開発も違いはありません。開発ツールがどのように働くのかを理解すれば、より快適に自信を持って使用できるのです。このドキュメントの目的は、どのようにLaravelが「働いて」いるのかの素晴らしい、ハイレベルな概論を理解してもらうためです。フレームワークの概論をより良く知ってもらうことで、全てに対し「不可解さ」が減り、より自信を持ってアプリケーションを開発してもらえます。さらに、リクエストライフサイクルの高いレベルの概論を理解してもらうため、"start"ファイルとアプリケーションイベントも取り扱いましょう。When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them. The goal of this document is to give you a good, high-level overview of how the Laravel framework "works". By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications. In addition to a high-level overview of the request lifecycle, we'll cover "start" files and application events.

これらの言葉を今すぐ理解できなくても、気落ちしないで下さい。ただ、何が行われているかを理解するための基本だけを理解してください。ドキュメントの他のセクションで明確にされる内容を理解すれば、知識は育っていくことでしょう。If you don't understand all of the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.

リクエストのライフサイクルRequest Lifecycle

アプリケーションに対するリクエストはすべて、public/index.phpスクリプトを通して受け付けられます。Apacheを使用している場合であれば、最初からLaravelに含まれている.htaccessファイルが、index.phpに全リクエストを渡す処理を行っています。この時点で、Laravelはリクエストの処理を開始し初め、そしてクライアントへレスポンスを返します。Laravelの初期化の手順を全般的に理解することは役立ちますので、説明していきましょう！All requests into your application are directed through the public/index.php script. When using Apache, the .htaccess file that ships with Laravel handles the passing of all requests to index.php. From here, Laravel begins the process of handling the requests and returning a response to the client. Getting a general idea for the Laravel bootstrap process will be useful, so we'll cover that now!

Laravelの初期化の手順に関して、一番理解しておくべき重要点はサービスプロバイダーです。app/config/app.php設定ファイルを開き、providers配列を見てもらえば、サービスプロバイダーのリストを見つけることができます。これらのサービスプロバイダーが、Laravelの初期化メカニズムの重要点です。しかし、サービスプロバイダーを探る前に、index.phpへ戻りましょう。index.phpファイルがリクエストを受け取ると、bootstrap/start.phpファイルがロードされます。このファイルはIoCコンテナとしても動作する、Laravel Applicationオブジェクトを生成します。By far, the most important concept to grasp when learning about Laravel's bootstrap process is Service Providers. You can find a list of service providers by opening your app/config/app.php configuration file and finding the providers array. These providers serve as the primary bootstrapping mechanism for Laravel. But, before we dig into service providers, let's go back to index.php. After a request enters your index.php file, the bootstrap/start.php file will be loaded. This file creates the new Laravel Application object, which also serves as an IoC container[/docs/4.2/ioc].

Applicationオブジェクトを生成したあと、プロジェクトのパスが設定され、環境の決定コードが実行されます。続いて、内部のLaravel初期化処理(bootstrap)スクリプトが呼び出されます。このファイルはLaravelのソースと深く関わっており、タイムゾーンのやエラーレポートのような設定ファイルに基づいた設定をいくつか行います。しかし、こうした追加の設定で重要なのは、些細なオプションの設定ではなく、アプリケーションの全サービスプロバイダーの登録です。After creating the Application object, a few project paths will be set and environment detection[/docs/4.2/configuration#environment-configuration] will be performed. Then, an internal Laravel bootstrap script will be called. This file lives deep within the Laravel source, and sets a few more settings based on your configuration files, such as timezone, error reporting, etc. But, in addition to setting these rather trivial configuration options, it also does something very important: registers all of the service providers configured for your application.

単純なサービスプロバイダーが持っているメソッドは、registerたった一つのみです。このregisterメソッドは、アプリケーションオブジェクト自身のregisterメソッドを通じ、アプリケーションがサービスプロバイダーを登録する時に呼び出されます。このメソッドにより、サービスプロバイダーはIoCコンテナを使い、色々登録します。重要なのは、それぞれのサービスプロバイダーがコンテナへ、アプリケーション内でサービスにアクセスするために結合されたクロージャーを一つ以上登録していることです。例えば、QueueServiceProviderはキューに関連する様々なクラスを解決するために、クロージャーを登録しています。もちろん、サービスプロバイダーはどんな初期化コードも書くことができ、IoCコンテナへの登録だけに限りません。サービスプロバイダーでイベントのリスナー、ビューコンポーサー、Artisanコマンドなども登録できます。Simple service providers only have one method: register. This register method is called when the service provider is registered with the application object via the application's own register method. Within this method, service providers register things with the IoC container[/docs/4.2/ioc]. Essentially, each service provider binds one or more closures[http://us3.php.net/manual/en/functions.anonymous.php] into the container, which allows you to access those bound services within your application. So, for example, the QueueServiceProvider registers closures that resolve the various Queue[/docs/4.2/queues] related classes. Of course, service providers may be used for any bootstrapping task, not just registering things with the IoC container. A service provider may register event listeners, view composers, Artisan commands, and more.

すべてのサービスプロバイダーが登録し終えたら、app/startファイル達がロードされます。続いて、app/routes.phpファイルがロードされます。routes.phpファイルがロードされたら、ルートへ送り出すためにRequestオブジェクトがアプリケーションに渡されます。After all of the service providers have been registered, your app/start files will be loaded. Lastly, your app/routes.php file will be loaded. Once your routes.php file has been loaded, the Request object is sent to the application so that it may be dispatched to a route.

では、まとめてみましょう。So, let's summarize:

1. リクエストがpublic/index.phpファイルに入ってくる。Request enters public/index.php file.
2. bootstrap/start.phpファイルがアプリケーションを生成し、環境を決定する。bootstrap/start.php file creates Application and detects environment.
3. framework/start.phpファイルが設定ファイルから設定を取り込み、サービスプロバイダーをロードする。Internal framework/start.php file configures settings and loads service providers.
4. アプリケーションがapp/start下のファイルをロードする。Application app/start files are loaded.
5. アプリケーションがapp/routes.phpファイルをロードする。Application app/routes.php file is loaded.
6. Requestオブジェクトがアプリケーションに送られ、Responseオブジェクトを送り返す。Request object sent to Application, which returns Response object.
7. Responseオブジェクトがクライアントに送り返される。Response object sent back to client.

これで、Laravelアプリケーションでどのようにリクエストが処理されるか理解できたと思います。次に、"start"ファイル達をもっと詳しく見てみましょう。Now that you have a good idea of how a request to a Laravel application is handled, let's take a closer look at "start" files!

スタートファイルStart Files

アプリケーションのスタートファイルはapp/startディレクトリーに設置されています。デフォルトでは３つがアプリケーションに含まれています。global.php、local.php、artisan.phpです。artisan.phpについての追加情報は、Artisanコマンドラインの章をご覧ください。Your application's start files are stored at app/start. By default, three are included with your application: global.php, local.php, and artisan.php. For more information about artisan.php, refer to the documentation on the Artisan command line[/docs/4.2/commands#registering-commands].

global.phpスタートファイルはデフォルトでは、いくつかの基本的な項目で構成されています。ログやapp/filters.phpファイルのインクルードなどです。しかしながら、このファイルにご希望のものを何でも自由に付け加えて構いません。環境とは関係なく、アプリケーションに対する全てのリクエストで自動的にこのファイルをインクルードします。その一方、アプリケーションがlocal環境で動作しているときにだけ、local.phpファイルを呼び出します。環境についての追加情報は、ドキュメントの環境の章をご覧ください。The global.php start file contains a few basic items by default, such as the registration of the Logger[/docs/4.2/errors] and the inclusion of your app/filters.php file. However, you are free to add anything to this file that you wish. It will be automatically included on every request to your application, regardless of environment. The local.php file, on the other hand, is only called when the application is executing in the local environment. For more information on environments, check out the configuration[/docs/4.2/configuration] documentation.

もちろん、localに加え、別の環境を用意したら、同様にその環境用のスタートファイルを作成できます。アプリケーションがその環境で実行される時に、自動的に読み込みます。 ですから、例えば、bootstrap/start.phpファイルの中で、developmentという環境を設定したら、アプリケーションがその環境でリクエストを受け取った時に読み込まれる、app/start/development.phpファイルを作成できます。Of course, if you have other environments in addition to local, you may create start files for those environments as well. They will be automatically included when your application is running in that environment. So, for example, if you have a development environment configured in your bootstrap/start.php file, you may create a app/start/development.php file, which will be included when any requests enter the application in that environment.

Startファイルへ何を設置するかWhat To Place In Start Files

Startファイルへはどんな「初期化」コードでも、簡単に設置することができます。例えば、ビューコンポーサーやログの準備、PHPのセッティングなどを登録できます。何に使用するかは、皆さんにお任せしています。もちろん、すべての初期化コードをstartファイルへ投げ込んでしまえば、ぐちゃぐちゃになるでしょう。大きなアプリケーションを開発する場合や、startファイルが混み合ってきたと感じたら、いくつかの初期化コードをサービスプロバイダーに移すことを考えて下さい。Start files serve as a simple place to place any "bootstrapping" code. For example, you could register a View composer, configure your logging preferences, set some PHP settings, etc. It's totally up to you. Of course, throwing all of your bootstrapping code into your start files can get messy. For large applications, or if you feel your start files are getting messy, consider moving some bootstrapping code into service providers[/docs/4.2/ioc#service-providers].

アプリケーションイベントApplication Events

アプリケーションイベントを登録するRegistering Application Events

また、リクエストの前後の処理を行うために、before、after、finish、shutdownアプリケーションイベントを登録することができます。You may also do pre and post request processing by registering before, after, finish, and shutdown application events:

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

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

イベントのリスナーは、アプリケーションへのリクエストごとに、その前(before)、その後(after)に実行されます。 これらのイベントはグローバルなフィルタリングやレスポンスの変更に役に立ちます。startファイルやサービスプロバイダーで登録できます。Listeners to these events will be run before and after each request to your application. These events can be helpful for global filtering or global modification of responses. You may register them in one of your start files or in a service provider[/docs/4.2/ioc#service-providers].

やってきたリクエストがルートに一致し、そのルートを実行する前に発行されるmatchedイベントのリスナーを登録することもできます。You may also register a listener on the matched event, which is fired when an incoming request has been matched to a route but that route has not yet been executed:

Route::matched(function($route, $request)
{
	//
});

finishイベントはアプリケーションがクライアントへレスポンスを送り終えた後に呼び出されます。これはアプリケーションに「最後の瞬間」に行われることを期待する処理を行うために最適です。shutdownイベントは、全finishイベントハンドラーの処理が完了したすぐ後に呼び出されます。スクリプトの終了直前、何かを実行する最後のチャンスです。しかしながら、この２つのイベントを利用する必要はほとんど無いでしょう。The finish event is called after the response from your application has been sent back to the client. This is a good place to do any last minute processing your application requires. The shutdown event is called immediately after all of the finish event handlers finish processing, and is the last opportunity to do any work before the script terminates. Most likely, you will not have a need to use either of these events.