Entering Passive Mode

今日は mask ルールだ。

このルールは非常に柔軟性が高く、
フィールドの値を正規表現で制限することができる。
これは文字列型のプロパティの検証として最適と言える。

例えば、ルールの処理は、allow か deny の値を取るので、
これを正規表現「^(?:allow|deny)$」で表すことができる。

では、Validator の設定に追加してみよう。

値の入力が必須である項目はほかにもあるので、
それらにも required ルールを適用してみよう。

備考以外は全て必須項目なので、required を適用できる。
プロトコルは String[] なので、ちょっと置いておき、
型が String である以下のプロパティに使ってみよう。

・rule.action
・rule.source.network
・rule.source.port
・rule.destination.network
・rule.destination.port

ERROR: Resource key "errors.required" not found in default bundle

このエラーメッセージから、以下のことが推測できる。

・Validator はエラーメッセージにリソースを使用している。
・キーが「errors.required」のリソースが必要である。
・リソースとして MessageResource が使われている。

「default bundle」というのは、
Struts 設定ファイルで指定した <message-resources> で、
key 属性を指定していないものを示している。

Validator 設定ファイルの基本は、
検証条件を表すフォームを定義することだ。

例を示した方が速いな。

========== /WEB-INF/validation.xml ==========
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE form-validation PUBLIC
        "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.3.0//EN"
        "http://jakarta.apache.org/commons/dtds/validator_1_3_0.dtd">

Struts Validator は、Struts の中核として、
struts-core ライブラリに含まれているのだが、
Validator の検証機能を実際に使うためには、
いくつかのライブラリを lib に追加する必要がある。

・commons-validator-1.3.0.jar
・oro-2.0.8.jar

これらは struts-1.3.5 と一緒に配布されているので、
/WEB-INF/lib にコピーしておくこと。

画面の遷移はすべて終わったので、
パケットフィルタの設定を全て操作できるようになったが、
まだ、フィルタルールの内容を検証する処理を書いていない。

以前作った、フィルタ情報の更新用フォームでは、
FilterInfoForm#validate に検証コードを書いていた。
フィルタ情報の検証は結構単純だったとは言え、
FilterInfoForm#validate のコードは結構長かった。

さて、フィルタルールの内容は結構複雑だ。
フィルタ情報と比べ、プロパティの数がはるかに多いため、
FilterRuleForm#validate に書くとすると、
非常に長いコードになることが想定される。

ルール編集画面は、ルール追加画面とほとんど同じなので、
edit-rule.jsp を流用することにしよう。

1 つの View を追加と編集に使う場合、
画面の一部分の表示を変えなければならない。
例えば、HTML のタイトルや、見出し部分だ。

これを実現するためには、JSP で追加か編集かを区別し、
出力する HTML を変える必要がある。

Logic タグライブラリを使えば、
リクエストやアプリケーション等の属性を元に、
JSP 内で条件分岐を行うことができる。

編集画面を出すためには、/filter/manage-rules から、
ルールの現在値を読み出すための別の Action に転送し、
その Action に FilterRuleForm を割り当てる必要がある。

初期化用のパスは /filter/edit-rule とし、
Action クラスは EditFilterRuleAction としておこう。

        <!-- ルール管理 -->

        <action path="/filter/manage-rules"
                name="manageFilterRulesForm" scope="request"
                parameter="command"
                type="jp.loafer.test.actions.ManageRulesAction">

編集用のボタンは少し特殊である。
ルールごとに個別にボタンが存在するため、
ボタンが複数存在することになる。

そのため、他のボタンと同じように扱おうとして、
command パラメータを使って値を設定しようとすると、
編集であることを表す値と、編集されるルールの番号を、
同時にパラメータで表現しなければならない。

でも、edit0 や edit1 等としてしまうと、
DispatchAction の メソッドに対応付けるのは無理がある。

今日は、対照的な処理を実装するだけ。楽だ楽だ。

下への移動は、上への移動とほぼ同じ。
しかし順番が変わるので、並べ替えは降順にする必要がある。

TreeSet には NavigableSet を実装しているので、
#descendingIterator メソッドで逆順 Iterator が得られる。
しかし、このインタフェースは 1.6 で追加されたものだし、
これでは拡張 for 文が使えなくなってしまう。

そこで、TreeSet の並べ替え法則を逆にすることを考える。
順序付けは、Comparator を指定することで行われるので、
自然順序付けと逆になるような Comparator を作り、
TreeSet のコンストラクタに渡せば良いのだ。