動作機構の概要
Yii アプリケーションが HTTP リクエストの処理を開始するたびに、おおよそのプロセスが実行されます。
以下の図は、アプリケーションがリクエストを処理する方法を示しています。
ブートストラッピング
ブートストラップとは、アプリケーションが新しく受け入れられたリクエストの解析と処理を開始する前に、事前に環境を準備するプロセスを指します。起動ガイダンスはエントリースクリプト(Entry Script)とアプリケーション本体(application)の2箇所で行われます。
エントリースクリプトでは、各クラスライブラリのクラスファイルオートローダー(Class Autoloader、以下オートローダー)を登録する必要があります。これには主に、autoload.php ファイル経由でロードされる Composer オートローダーと、Yii クラス経由でロードされる Yii オートローダーが含まれます。次に、エントリ スクリプトはアプリケーションの構成を読み込み、アプリケーション プリンシパルのインスタンスを作成します。
アプリケーション本体のコンストラクターでは、次のガイダンス作業が実行されます:
ブートストラップは各リクエストを処理する前に実行する必要があるため、このプロセスを可能な限り軽量にすることが非常に重要です。このステップを可能な限り最適化してください。
ブートコンポーネントを登録しすぎないように注意してください。 HTTP リクエスト処理のライフサイクル全体を通じて機能する必要がある場合にのみ使用する必要があります。その使用例を挙げると、モジュールで追加の URL 解析ルールを登録する必要がある場合は、リクエストを解析する前に URL 解析ルールが有効になるように、アプリケーションのブートストラップ属性にそのルールを登録する必要があります。 (注釈: つまり、パフォーマンスのニーズのために、URL 解析などのいくつかの操作を除いて、ほとんどのコンポーネントはブート プロセス中にすべてロードされるのではなく、オンデマンドでロードされる必要があります。)
実稼働環境では、APC などのバイトコード キャッシュをオンにして、PHP ファイルのロードと解析に必要な時間をさらに最小限に抑えることができます。
一部の大規模なアプリケーションには、非常に複雑なアプリケーション構成が含まれており、多くの小さな構成ファイルに分割されています。この時点で、エントリ スクリプトがアプリケーション インスタンスを作成する前に、構成配列全体をキャッシュし、キャッシュから直接ロードすることを検討できます。
yiiエントリーファイル
ここではサードパーティの設定管理プラグインが使用されています: marcovwout は Yii 設定を管理します。詳細については説明しません。残っているのは、基本的なグローバル変数の設定だけです。設定配列を Yii::createWebApplication に渡し、run メソッドを呼び出します。Web アプリケーションは実行中ですか? はい、最上位レベルの抽象化は次のようになります。対応する設定をコンテナに渡すと、アプリケーションが実行できるようになります。通常はこの構成に基づいています。
YiiBase の 2 つの重要なメソッド (インポート、オートロード) について話しましょう
ここではサードパーティの設定管理プラグインが使用されています: marcovwout は Yii 設定を管理します。詳細については説明しません。残っているのは、基本的なグローバル変数の設定だけです。設定配列を Yii::createWebApplication に渡し、run メソッドを呼び出します。Web アプリケーションは実行中ですか? はい、最上位レベルの抽象化は次のようになります。対応する設定をコンテナに渡すと、アプリケーションが実行できるようになります。通常はこの構成に基づいています。
ルーティング
エントリ スクリプトが yiiwebApplication::run() メソッドを呼び出すと、最初に実行される操作は入力リクエストを解析し、次に対応するコントローラー操作をインスタンス化してリクエストを処理することです。このプロセスはルーティングと呼ばれます。 (翻訳注: 中国語では動詞でもあり名詞でもあります)
ルーティングを解決する
ルーティング ガイダンスの最初のステップは、受信リクエストを解析してルートを作成することです。 「コントローラー」の章で説明したように、ルートはコントローラーのアクションを見つけるために使用されるアドレスです。このプロセスは、リクエスト アプリケーション コンポーネントの yiiwebRequest::resolve() メソッドを通じて実装され、URL マネージャーを呼び出して実際のリクエスト解決を実行します。
デフォルトでは、受信リクエストには r という名前の GET パラメータが含まれ、その値はルートとして扱われます。ただし、yiiwebUrlManager::enablePrettyUrl を有効にすると、リクエストのルートを決定するときにさらに多くの処理が発生します。具体的な詳細については、URL の解析と生成の章を参照してください。
最終的にルートを決定できない場合、リクエスト コンポーネントは yiiwebNotFoundHttpException 例外 (注釈: 有名な 404) をスローします。
デフォルトルート
受信リクエストが特定のルートを提供しない場合 (通常、これはホームページへのリクエストです)、 yiiwebApplication::defaultRoute 属性で指定されたデフォルト ルートが有効になります。このプロパティのデフォルト値は site/index で、サイト コントローラーのインデックス アクションを指します。次のように、アプリ構成でこのプロパティの値を調整できます:
リーリーcatchAll ルーティング (完全なインターセプト ルーティング)
すべてのリクエストで同じ情報ページが表示されるように、Web アプリケーションを一時的にメンテナンス モードにしたい場合があります。もちろん、これを達成する方法はたくさんあります。最も簡単かつ最速の方法は、アプリケーション設定で yiiwebApplication::catchAll 属性を設定することです:
リーリーcatchAll 属性は、配列でパラメーターとして渡す必要があります。配列の最初の要素はルートであり、残りの要素は操作にバインドされたパラメーターを (名前と値のペアの形式で) 指定します。
catchAll 属性が設定されている場合、受信リクエストから解析されたすべてのルートが置き換えられます。この設定では、すべての受信リクエストの処理に使用されるアクションは同じサイト/オフラインになります。
アクションを作成する
リクエストルートが決定したら、次のステップはルートに応答する「アクション」オブジェクトを作成することです。
ルートは内部のスラッシュを使用して複数のコンポーネント フラグメントに分割できます。たとえば、サイト/インデックスはサイトとインデックスの 2 つの部分に分解できます。各フラグメントは、モジュール、コントローラー、またはアクションを指す ID です。
ルートの最初のフラグメントから開始して、アプリケーションは次のプロセスを実行して、モジュール (存在する場合)、コントローラー、およびオペレーションを作成します。