Struts での Validator フレームワークの使用

すべてのアプリケーションには、バックエンド データベースに挿入するデータが合法かつ有効であることを確認する責任があります。結局のところ、これらのアプリケーションが依存しているデータが侵害された場合、それは壊滅的なことになります。自分自身を適切に機能させるには？たとえば、正式なリレーショナル データベースを使用するアプリケーションでは、データベース内の各フィールドには、データベースに格納されているデータがある程度正しいことを保証するための独自のルールと制約があります。バックエンド リポジトリ データを使用するアプリケーションは、送信するデータの整合性を保護する責任があります。

標準を満たさないデータを挿入または更新しようとすると、発見されて拒否される可能性があります。この種の検出はアプリケーションの隅々まで広がる可能性があり、ビジネス ロジック層で一部の検証が実行される場合があり、通常、ビジネス ロジック オブジェクトにもビジネス ロジック検証があり、データもバックグラウンドでチェックする必要があります。データベース。

残念ながら、この種の検証はアプリケーション内で広く行われているため、アプリケーションはデータを検証する際にある程度のコードの冗長性を持たせることになります。これはアプリケーションが望んでいることではありません。複数の場所で作業が重複するため、アプリケーションのデプロイメントとメンテナンスにさらに時間がかかるからです。これらの検証ルールをアプリケーション全体で再利用できれば、アプリケーションの柔軟性が高まり、デプロイがより速くなり、カスタマイズが容易になり、プログラムの柔軟性も高まります。

Jakarta Commons Project Validator Framework Introduction
Validator は、David Winterfeldt によって作成されたオープンソース プロジェクトであり、Jakarta Commons のサブプロジェクトでもあります。 Commons プロジェクトは主に、Validator などのいくつかの再利用可能なコンポーネントを提供します。その他のよく知られた Commons コンポーネントには、BeanUtils、Digester、Logging Framework などがあります。 Validator バージョン 1.0 は、2002 年 11 月初旬にリリースされました。

Validator を使用する利点
. Validator フレームワークを使用すると、アプリケーション コードで検証ルールを一般的に定義する場合と比べて、次のような多くの利点があります。
. サーバー側とクライアント側の検証ルールを同じ場所で定義できます。
国際化をサポートします。 Web アプリケーションや標準的な Java アプリケーションに使用されます。
. プログラミングではなく、宣言的なメソッドを使用して実装します。
さらに、Validator の最大の特徴は、プラグ可能性をサポートしていることです。この記事の後半では、Validator フレームワークの組み込み検証ルールを使用して作業をより適切に完了する方法を説明します。さらに重要なのは、Validator フレームワークではバリデータをカスタマイズしてフレームワークに挿入できることです。

StrutsとValidatorの関係
Validatorフレームワーク自体がStrutsフレームワーク上に構築されていることを指摘しておきます。 Validator の作成者である David Winterfeldt は、Struts を使用する過程で、多くの ActionForm クラスで同じ検証ルールを繰り返し使用する必要があり、その結果コードの冗長性が高くなることに気づきました。そこで彼は、この冗長性を排除するために Validator フレームワークを作成することを決定し、Validator が誕生しました。

Validator アーキテクチャは元々 Struts アーキテクチャ用に生まれましたが、Struts アーキテクチャから独立して使用できるように設計および構築されています。この機能により、Struts ベースかどうかに関係なく、このフレームワークを任意のアプリケーションで使用できるようになります。 Struts フレームワークを使用しないからといって、アプリケーションにおける Validator アーキテクチャの役割には影響しません。実際、これが、Validator が Struts プロジェクトの直接の一部ではなく、Jakarta Commons プロジェクトの一部である理由です。

それでは、このフレームワークを Struts ベースのアーキテクチャのような Web アプリケーションに統合してみましょう。この記事の最後では、EJB ベースのアプリケーションなど、他の種類のアプリケーションにこれを適用する方法を紹介します。

Validator コンポーネントの概要
Validator アーキテクチャは次のコンポーネントで構成されます:
Validator; A Validator は、Validator フレームワークによって呼び出される Java クラスです。フレームワークは、構成ファイルで定義されたメソッド シグネチャに基づいて、この Validaotor クラスを呼び出します。通常、各 Validator クラスは個別の検証ルールを提供し、これらを組み合わせてより複雑なルール セットを作成できます。

注: 場合によっては、便宜上、Validator クラスで複数の検証ルールを定義することもできます。各ルールは静的メソッドであり、クライアント状態情報は含まれません。

フレームワークには 14 のデフォルトの検証ルールが用意されており、これらのルールは Validator フレームワークの「基本ルール」とも呼ばれます。これらの基本ルールは表 1 に示すとおりです。byte、short、integer、値が対応する基本データ型に変換できるかどうかを検証します
Long、float、double
CreditCard 入力フィールドが有効なクレジット カード番号であるかどうかを検証します
date 入力フィールドが有効な日付であるかどうかを検証します
email 入力フィールドが正規表現と正常に一致するかどうかを確認します
maxLength 値の長さが指定された最大長以下であるかどうかを確認します
minLength 値の長さが指定された最小長以上であるかどうかを確認します
range 値の範囲が最大値と最小値の間にあるかどうかを確認します
必須 入力フィールドが空でないか、またはスペースを含まない値の長さが0より大きいかどうかを確認します
表1
表 1 からわかるように、Validator フレームワークは、Web アプリケーションに必要な検証ルールのほとんどを提供します。これらの既存の検証ルールを使用して、独自の検証プロファイルを作成できます。それでも、前述したように、また後で説明するように、ニーズに応じてさらにバリデーターを自由に追加できます。

それでは、Struts アーキテクチャに基づいたアプリケーションでこれらの基本的なバリデーターを構成して使用する方法について説明します。
Validator フレームワークを柔軟にしているのは、すべての検証ルールとその特定の詳細が外部ファイルの構成宣言を通じて実装されていることです。アプリケーションはこれらの特定の検証ルールを知る必要はありません。この機能を使用すると、アプリケーションのソース コードに触れることなく、ルールセットを拡張および変更できます。これは、各インストールをパーソナライズしたい場合、またはニーズが変化した場合に非常に重要です。
Struts 1.1 の Validator フレームワークを使用する場合、2 つの構成ファイルを使用します。1 つは validator-rules.xml と呼ばれ、もう 1 つは実際には validation.xml と呼ばれます。これらに任意の名前を付けることも、Merged という名前を付けることもできます。 1 つの XML ファイルにまとめられます。ただし、それぞれに独自の用途があるため、分けて保管することをお勧めします。

注: Jakarta Web サイトから Validator をダウンロードした場合、これら 2 つのファイルは含まれません。これら 2 つのファイルは、Validator フレームワークを含む Struts ダウンロードにのみ含まれています。
validator-rules.xml ファイル
validator-rules.xml ファイルは、アプリケーションが使用できるバリデーターを定義します。 validator-rules.xml はテンプレートとして機能し、すべてのアプリケーションで使用できるバリデーターを定義します。

注: この XML ファイルと、以下で説明する別の XML ファイルは、クラス ローダーが見つけられる場所に配置する必要があります。 Web アプリケーションで Validator フレームワークを使用する場合、正しい場所は WEB-INF の下にある必要があります。
validator-rules.xmlファイルは、jakarta.apache.org/struts/dtds/validator-rules_1_1.dtdからダウンロードできるvalidator-rules_1_1.dtdの管理対象となります。このファイルの具体的な詳細を検討するのにあまり時間をかけたくありません。ここでは基本的な概要のみを説明します。
validator-rules.xml ファイルの最も重要な要素は、 要素に含まれています。例 1:
例 1: 単純な validator-rules.xml ファイル

< ;global> ;
ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest"
msg="errors.required"/ >

classname="org.apache.struts.util.StrutsValidator"
method="validateMinLength"
methodparams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,




アプリケーションによって使用される各 Validator は、 要素に対応します。例 1 では、2 つのバリデーターを示します。1 つはリクエスト バリデーターで、もう 1 つは最小長のバリデーターです。 要素は多くの属性をサポートします。これらのプロパティは、このバリデーターがどの正しいクラスとメソッドを呼び出す必要があるかをフレームワークに伝えるために必要です。たとえば、例 1 の request Validator 要素は、この Validator が org.apache.struts.util.StrutsValidator クラスの validateRequest() メソッドを呼び出すことを示しています。バリデーターは別のバリデーターに依存することもあります。たとえば、例 1 の最小長のバリデーターには、このバリデーターが要求元のバリデーターに依存することを示すために使用される、depends 属性が含まれています。 msg 属性は、フレームワークが正しいエラー メッセージを生成するために使用するキー値とリソース バインディングを指定します。リソース バインディングの使用は、エラー メッセージのローカライズに役立ちます。
要素は サブ要素もサポートしており、クライアントによって実行される JavaScript 関数を指定できます。このようにして、サーバー側とクライアント側の検証を同じ場所で指定できるため、アプリケーションのメンテナンスが簡単になります。

Validation.xml ファイル
Validator フレームワークの 2 番目の構成ファイルは、この validation.xml というファイルです。実際、上記は Struts での Validator フレームワークの使用に関する内容です。その他の関連記事については、PHP 中国語 Web サイト (www.php.cn) に注目してください。