Apache-tapestry-architecture
Apacheタペストリー-アーキテクチャ
Tapestryは、可能な限りJavaの利用可能な機能を使用しようとします。 たとえば、すべてのTapestryページは単なるPOJOです。 アプリケーションを作成するためのカスタムインターフェイスや基本クラスを強制しません。 代わりに、アノテーション（Javaクラスの機能を拡張するための軽量オプション）を使用して機能を提供します。 バトルテスト済みの Java Servlet API に基づいており、サーブレットフィルターとして実装されています。 Webアプリケーションに新しい次元を提供し、プログラミングは非常にシンプルで、柔軟で、理解しやすく、堅牢です。
ワークフロー
タペストリーページが要求されたときに行われる一連のアクションについて説明します。
ステップ1 *- *Java Servlet はページ要求を受け取ります。 このJavaサーブレットは、着信要求がタペストリーに転送されるように構成されています。 設定は、次のプログラムで指定されている web.xml で行われます。 フィルターおよびフィルターマッピングタグは、すべてのリクエストを_Tapestry Filter_にリダイレクトします。
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>My Tapestry Application</display-name>
<context-param>
<param-name>tapestry.app-package</param-name>
<param-value>org.example.myapp</param-value>
</context-param>
<filter>
<filter-name>app</filter-name>
<filter-class>org.apache.tapestry5.TapestryFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>app</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>ステップ2 *- *Tapestry Filter は、* Service（）メソッドによって *HttpServletRequestHandler サービスを呼び出します。
ステップ3 *- *HttpServletRequestHandler は、リクエストとレスポンスを RequestGlobals に保存します。 また、要求と応答をRequest and Responseオブジェクトとしてラップし、RequestHandlerに送信します。
ステップ4 *- *RequestHandler は、Servlet APIの HttpServletRequest を抽象化したものです。 タペストリーの顕著な特徴のいくつかは RequestHandler セクションで行われます。 タペストリーの機能は、RequestHandlerにフィルターを記述することで拡張できます。 RequestHandlerは、以下を含むいくつかの組み込みフィルターを提供します-
- CheckForUpdates Filter -ライブクラスのリロードを担当します。 このフィルターは、Javaクラスの変更を確認し、必要に応じてアプリケーションを更新します。
- ローカリゼーションフィルター-ユーザーの場所を特定し、アプリケーションのローカリゼーションサポートを提供します。
- StaticFiles Filter -静的リクエストを特定し、プロセスを中止します。 プロセスが中止されると、Javaサーブレットが制御を取得してリクエストを処理します。
- エラーフィルター-キャッチされなかった例外をキャッチし、例外レポートページを表示します。
RequestHandlerは、RequestQlobal内の要求と応答を変更および保存し、MasterDispatcherサービスを呼び出します。
ステップ5 *- *MasterDispatcher は、特定の順序で複数のディスパッチャを呼び出してページをレンダリングします。 MasterDispatcherによって呼び出される4つの主要なディスパッチャは次のとおりです-
- RootPath Dispatcher -要求のルートパス「/」を認識し、開始ページと同じものをレンダリングします。
- Asset Dispatcher -URLパターン/assets/を確認することでアセット（Javaアセット）リクエストを認識し、リクエストされたアセットをバイトストリームとして送信します。
- PageRender Dispatcher -タペストリー操作の大部分はPageRender Dispatcherおよび次のディスパッチャコンポーネントDispatcherで実行されます。 このディスパッチャは、そのリクエストの特定のページとそのアクティベーションコンテキスト（追加情報）を認識します。 次に、その特定のページをレンダリングし、クライアントに送信します。 たとえば、リクエストURLが/product/12123434の場合、ディスパッチャはproduct/12123434という名前のクラスが使用可能かどうかを確認します。 見つかった場合は、product/12123434クラスを呼び出し、応答を生成してクライアントに送信します。 そうでない場合、製品クラスをチェックします。 見つかった場合は、追加情報121234434を使用して製品クラスを呼び出し、応答を生成してクライアントに送信します。 この追加情報は、アクティベーションコンテキストと呼ばれます。 クラスが見つからない場合、要求はコンポーネントディスパッチャに転送されます。
- コンポーネントディスパッチャー-コンポーネントディスパッチャーは、パターンのページのURLと一致します-/<class_name>/<component_id>：<event_type>/<activation_context>。 たとえば、/product/grid：sort/ascは、製品クラス、グリッドコンポーネント、sorteventタイプ、ascアクティベーションコンテキストを表します。 ここで、event_typeはオプションであり、何も指定されていない場合、デフォルトのイベントタイプアクションがトリガーされます。 通常、コンポーネントディスパッチャーの応答は、リダイレクトをクライアントに送信することです。 ほとんどの場合、リダイレクトは次のリクエストでPageRender Dispatcherと一致し、適切な応答がクライアントに送信されます。
