Jakarta Struts 1.1 (2) の学習

DynaActionForm

DynaActionFormは、基本的にActionFormを書く必要をなくす便利な仕組みを提供します。 DynaActionForm では動的なフォーム プロパティが可能です。これは、struts-config.xml ファイルでプロパティを定義し、フォーム タイプを org.apache.struts.action.DynaActionForm に設定できることを意味します。何も書く必要はありません。 DynaActionForm は、Apache パブリック プロジェクトの DynaBean を使用して、これらの操作を完了します。この動的な動作は、リフレクションとハッシュマップを通じて提供されます。

DynaActionFormはstruts-config内のタグを使用して定義されています。属性名はアクション内のフォーム Bean のインデックスに使用され、タイプはインスタンス化されたクラスを指定するために使用されます。 DynaActionForm クラスを使用する場合、動的プロパティは自動的にデフォルトで true に設定されます。 DynaActionForm の場合、フォームのすべてのプロパティは要素を使用して指定されます。要素内の名前は属性名を指します。 Type は、Bean 属性の Java 実装クラスのクラス名を参照します。この属性がインデックス型の場合は、型の後に「[ ]」を追加します。上の表では、最後の属性ジャンルの定義に注目してください。初期値 (またはデフォルト値) は「ダンス」に設定されています。この値は、DynaActionForm のreset() メソッドが呼び出されたときにデフォルト値としても設定され、フォームにデフォルト値を設定するメカニズムを許可します。初期属性に値が指定されていない場合、すべてのプリミティブ型の初期値は 0 に設定され、オブジェクトの場合、初期値は null (空) になります。

DynaActionForm を使用する主な利点の 1 つは、非常に少ないコードを記述するだけで済むことです。他のフォームと同様に、前述のコード例は、フォームを使用するために必要なすべてのコードです。知っておくべきことの 1 つは検証です。 DynaActionFormを利用する場合は、ActionFormとは少し異なり、どこかで検証処理が行われることが前提となります。独自のアクションに検証を実装することもできますが、これはより良いアプローチです。

検証には、DynaValidatorForm または DynaValidatorActionForm を使用できます。どちらのクラスも org.apache.struts.validator パッケージに含まれています。 DynaActionForm を拡張することで、XML ファイルの基本値フィールドに基づいて検証を行うことができます。検証はバリデーターに入力されたキーに基づいて行われます。キーは、struts-config.xml ファイルの name 属性です。これは、validation.xml ファイルの form 要素の name 属性と一致する必要があります。

複数のアプリケーションのサポート
Struts 1.1では、複数のサブアプリケーションを定義してサポートできます。これは、アプリケーションをより保守しやすいサブアプリケーションに配置できることを意味します。単一の struts-config.xml ファイルの外部でソース管理を検出する必要はなくなりました。

サブアプリケーションを使用するもう 1 つの理由は、クライアントに基づいて制御フローを変更することです。一部のアプリケーションでは、いくつかの共通ページがある場合がありますが、アプリケーションにログインするクライアントに応じて制御フローが変わる場合があります。この制御フローのメタデータをデータベースに保存し、別の struts-config.xml ファイルとともに web.xml ファイル (またはその一部) を生成できます。

Struts 1.x 向けに開発したことがある方は、web.xml ファイル内の多くの要素が Struts 1.1 の struts-config.xml ファイルに移動されていることに気付いたかもしれません。これは、それらがアプリケーション固有になっているためです。複数のサブアプリケーションは、リクエスト URI の相対コンテキスト部分で始まるプレフィックスによって識別されます。一致するアプリケーション プレフィックスがない場合は、デフォルトの構成が選択されます。デフォルト設定には空の文字列プレフィックスが付いています。デフォルト設定を実装するこの方法は、アプリケーションを 1 つだけ定義できる Struts 1.0.x と下位互換性があります。

さまざまな機能モジュールを含む大規模なアプリケーションがある場合、1 つの巨大なアプリケーションを一緒に実行されるサブアプリケーションに置き換える方が合理的です。以下に示す web.xml ファイルは、サブアプリケーションを定義する方法を示しています。


config
/WEB-INF/struts-config-config.xml





config/catalog
/WEB-INF/struts-config-catalog.xml





config/sorter
/ WEB-INF/struts-config-sorter.xml



サブアプリケーションを使用する場合、どのサブアプリケーションが使用されるかを指定するためにコンテキスト依存のリクエスト URI を定義できます。たとえば、フォーム上のアクションは、デフォルトのサブアプリケーションを参照する


、またはカタログ サブアプリケーションのアクション クラスを参照する


のようになります。実際にはこれを行う必要はありません。これを行う場合は、カタログ サブアプリケーションで /listCds を使用できます。基本的なルールは次のとおりです。バージョン 1.0 ではコンテキスト依存だったすべての struts-config.xml パラメーターは、バージョン 1.1 ではサブアプリケーションのプレフィックス固有になります。このようにして、単一のアプリケーションを変更せずにデフォルトのサブアプリケーションと指定されたサブアプリケーションの両方として機能させることができます。

上記は Jakarta Struts 1.1 (2) の学習内容です。その他の関連記事については、PHP 中国語 Web サイト (www.php.cn) に注目してください。