リクエスト処理
一旦 Pyramid アプリケーションが起動すると、リクエストを受け付け
てレスポンスを返す準備ができます。 WSGI リクエストが
Pyramid アプリケーションに入力された時から Pyramid が上流
の処理のための WSGI にレスポンスを返すまでの間に、何が起こるのでしょうか。
- ユーザは、ブラウザから Pyramid アプリケーションで使われる WSGI
サーバのホスト名およびポート番号に対してリクエストを開始します。
- Pyramid アプリケーションによって使用される WSGI サーバは、
Pyramid router オブジェクトの __call__ メソッドに
WSGI 環境変数を渡します。
- WSGI 環境変数に基づいて request オブジェクトが作成されます。
- 前のステップで作成された application registry と
request オブジェクトが、
get_current_request() および
get_current_registry() という名前の関数
が動作するように Pyramid が使用する thread local
スタックに push されます。
- NewRequest event がすべての
subscriber に送られます。
- アプリケーション設定内に route が定義されている場合、
Pyramid router は URL dispatch “route
mapper” を呼び出します。 mapper の仕事は、どのユーザ定義の
route が現在の WSGI 環境に一致するかを判断するために
リクエストを検査することです。 router はリクエストを
引数として mapper に渡します。
- いずれかの route が一致した場合、 route mapper はリクエストに属性を
追加します: matchdict と matched_route 属性がリクエスト
オブジェクトに追加されます。前者はリクエストの PATH_INFO 値の
一致した動的要素を表わす辞書を含んでいます。後者は、一致した route を
表わす IRoute オブジェクトを含んでいます。
見つかった route に関連した root オブジェクトも生成されます: 一致した
route configuration が関連する factory 引数を持っている場合、
この factory は root オブジェクトを生成するために使われます。
そうでなければデフォルトの root factory が使われます。
- route マッチが 見つからず 、 root_factory 引数が
Configurator コンストラクタに渡された場合、その callable が
root オブジェクトを生成するために使用されます。 Configurator
コンストラクタに渡された root_factory 引数が None だった場合、
デフォルトの root factory が root オブジェクトを生成するために使用されます。
- Pyramid router は、 root オブジェクトおよびリクエストを備えた
「トラバーサー」関数を呼びます。トラバーサー関数は context
を見つけるために (root オブジェクトかサブオブジェクト上のいずれかの既存の
__getitem__ を使用して) root オブジェクトをトラバースしようとします。
root オブジェクトに __getitem__ メソッドがない場合、 root はそれ
自身コンテキストであると仮定されます。正確なトラバーサルアルゴリズムは
Traversal で述べられています。トラバーサー機能は辞書
を返します。それは他の補足情報と同様に context と
view name も含んでいます。
- そのリクエストは、トラバーサーから返された様々な (context や
view_name などのような) 名前でデコレートされます。したがって、
例えば view コード内で request.context などでアクセス
することができます、
- ContextFound event がすべての
subscriber に送られます。
- Pyramid は context, request, ビュー名を使用して
view callable を見つけます。ビュー callable が (context の型、
request の型、ビュー名の値、およびビュー設定に適用された任意の
predicate 属性に基づいて)オブジェクトのこの組み合わせに対して
存在しない場合、 Pyramid は
HTTPNotFound 例外を上げます。
これは、上位の exception view によって捕捉されることを意図
しています。
- ビュー callable が見つかった場合、 Pyramid はそれを呼び出そう
とします。 authorization policy が使用されており、ビュー設定が
permission によって保護される場合、 Pyramid はコンテキスト
に取り付けられたリクエストの credential 情報およびセキュリティ
情報に基づいて、呼び出そうとしているビュー callable がリクエストした
ユーザによって実行可能かどうかを決定します。ビュー callable が許可
される場合、 Pyramid はレスポンスを得るためにそのビュー callable
を呼び出します。ビューの実行が禁止される場合、 Pyramid は
HTTPForbidden 例外を上げます。
- root factory の内で traversal や view
callable あるいは Pyramid 自身によって例外が上げられる場合
(HTTPNotFound または
HTTPForbidden が上がる場合のように)、
router は例外を捕捉し、それを exception 属性として request に
取り付けます。その後、捕捉された例外用の exception view
を見つけようとします。例外ビュー callable が見つかった場合、
callable が呼ばれ、レスポンスを生成するとみなされます。
例外と一致する exception view を見つけることができない場合、
例外が再送されます。
- 通常の view callable あるいは exception view
callable によって response を生成することに成功した場合だけ
次のステップが生じます。 Pyramid は、
add_response_callback() によって
取り付けられたすべての response callback メソッドを実行しよ
うとします。その後、 NewResponse
event がすべての subscriber に送られます。その後、WSGI
レスポンスを生成するために responseオブジェクトの __call__
メソッドが使用されます。レスポンスは上流の WSGI サーバに送られます。
- Pyramid は、
add_finished_callback() によって取り
付けられたすべての finished callback 関数も実行しようとします。
- thread local スタックが pop されます。
これは様々な詳細を省略した非常に高レベルの概観です。トラバーサル、URL
ディスパッチ、ビュー、イベント処理のような Pyramid router によって
起動されたサブシステムに関するより詳細については、
URL Dispatch, ビュー, Using Events
を見てください。