リクエスト処理

一旦 Pyramid アプリケーションが起動すると、リクエストを受け付け てレスポンスを返す準備ができます。 WSGI リクエストが Pyramid アプリケーションに入力された時から Pyramid が上流 の処理のための WSGI にレスポンスを返すまでの間に、何が起こるのでしょうか。

1. ユーザは、ブラウザから Pyramid アプリケーションで使われる WSGI サーバのホスト名およびポート番号に対してリクエストを開始します。

2. Pyramid アプリケーションによって使用される WSGI サーバは、 Pyramid router オブジェクトの __call__ メソッドに WSGI 環境変数を渡します。

3. WSGI 環境変数に基づいて request オブジェクトが作成されます。

4. 前のステップで作成された application registry と request オブジェクトが、 get_current_request() および get_current_registry() という名前の関数 が動作するように Pyramid が使用する thread local スタックに push されます。

5. NewRequest event がすべての subscriber に送られます。

6. アプリケーション設定内に route が定義されている場合、 Pyramid router は URL dispatch “route mapper” を呼び出します。 mapper の仕事は、どのユーザ定義の route が現在の WSGI 環境に一致するかを判断するために リクエストを検査することです。 router はリクエストを 引数として mapper に渡します。

7. いずれかの route が一致した場合、 route mapper はリクエストに属性を 追加します: matchdict と matched_route 属性がリクエスト オブジェクトに追加されます。前者はリクエストの PATH_INFO 値の 一致した動的要素を表わす辞書を含んでいます。後者は、一致した route を 表わす IRoute オブジェクトを含んでいます。 見つかった route に関連した root オブジェクトも生成されます: 一致した route configuration が関連する factory 引数を持っている場合、 この factory は root オブジェクトを生成するために使われます。 そうでなければデフォルトの root factory が使われます。

8. route マッチが 見つからず 、 root_factory 引数が Configurator コンストラクタに渡された場合、その callable が root オブジェクトを生成するために使用されます。 Configurator コンストラクタに渡された root_factory 引数が None だった場合、 デフォルトの root factory が root オブジェクトを生成するために使用されます。

9. Pyramid router は、 root オブジェクトおよびリクエストを備えた 「トラバーサー」関数を呼びます。トラバーサー関数は context を見つけるために (root オブジェクトかサブオブジェクト上のいずれかの既存の __getitem__ を使用して) root オブジェクトをトラバースしようとします。 root オブジェクトに __getitem__ メソッドがない場合、 root はそれ 自身コンテキストであると仮定されます。正確なトラバーサルアルゴリズムは Traversal で述べられています。トラバーサー機能は辞書 を返します。それは他の補足情報と同様に context と view name も含んでいます。

10. そのリクエストは、トラバーサーから返された様々な (context や view_name などのような) 名前でデコレートされます。したがって、 例えば view コード内で request.context などでアクセス することができます、

11. ContextFound event がすべての subscriber に送られます。

12. Pyramid は context, request, ビュー名を使用して view callable を見つけます。ビュー callable が (context の型、 request の型、ビュー名の値、およびビュー設定に適用された任意の predicate 属性に基づいて)オブジェクトのこの組み合わせに対して 存在しない場合、 Pyramid は HTTPNotFound 例外を上げます。 これは、上位の exception view によって捕捉されることを意図 しています。

13. ビュー callable が見つかった場合、 Pyramid はそれを呼び出そう とします。 authorization policy が使用されており、ビュー設定が permission によって保護される場合、 Pyramid はコンテキスト に取り付けられたリクエストの credential 情報およびセキュリティ 情報に基づいて、呼び出そうとしているビュー callable がリクエストした ユーザによって実行可能かどうかを決定します。ビュー callable が許可 される場合、 Pyramid はレスポンスを得るためにそのビュー callable を呼び出します。ビューの実行が禁止される場合、 Pyramid は HTTPForbidden 例外を上げます。

14. root factory の内で traversal や view callable あるいは Pyramid 自身によって例外が上げられる場合 (HTTPNotFound または HTTPForbidden が上がる場合のように)、 router は例外を捕捉し、それを exception 属性として request に 取り付けます。その後、捕捉された例外用の exception view を見つけようとします。例外ビュー callable が見つかった場合、 callable が呼ばれ、レスポンスを生成するとみなされます。 例外と一致する exception view を見つけることができない場合、 例外が再送されます。

15. 通常の view callable あるいは exception view callable によって response を生成することに成功した場合だけ 次のステップが生じます。 Pyramid は、 add_response_callback() によって 取り付けられたすべての response callback メソッドを実行しよ うとします。その後、 NewResponse event がすべての subscriber に送られます。その後、WSGI レスポンスを生成するために responseオブジェクトの __call__ メソッドが使用されます。レスポンスは上流の WSGI サーバに送られます。

16. Pyramid は、 add_finished_callback() によって取り 付けられたすべての finished callback 関数も実行しようとします。

17. thread local スタックが pop されます。

これは様々な詳細を省略した非常に高レベルの概観です。トラバーサル、URL ディスパッチ、ビュー、イベント処理のような Pyramid router によって 起動されたサブシステムに関するより詳細については、 URL Dispatch, ビュー, Using Events を見てください。