このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
Struts のコーディングは、イベント駆動型である。
リクエストが到達すると、まず Struts が処理をした後、
Action のコードが呼び出せる順番となっている。
そうなると、ActionForm が用意される前に、
HttpServletRequest#setCharacterEncoding を呼ぶためには、
何らかの方法で Struts の処理に介入しなければならない。
これには、大雑把に分けて 3 つの方法がある。
1. ActionServlet を継承したクラスを作って置き換え
2. RequestProcessor に独自の動作を登録
3. Servlet 2.3 規格の Filter を実装して前処理
1 は、一番簡単に思いつく方法である。
Struts の Servlet である ActionServlet を継承し、
独自の処理を加えたクラスを作り、
それを web.xml に登録して実行する方法だ。
ただ、思いつくのは簡単なのだが、
ActionServlet は非常に大きいクラスであるため、
それを継承してうまく実装するのは大変そうである。
2 は、Struts に独自処理を加えるには最適な方法だ。
Struts は、ActionServlet がリクエストを受け取ってから、
ユーザ定義の Action を呼び出すまでの間に、
色々な処理を行っているが、それら処理は
RequestProcessor というクラスに集約されている。
Struts 1.3 では、RequestProcessor の実装として
ComposableRequestProcessor というクラスを利用している。
ComposableRequestProcessor では、
個々の処理を Command というクラスに分離し、
それらの組み合わせを設定ファイルによって定義し、
「Chain of Responsibility」デザインパターンに基づき、
処理を連鎖させて実行するという特性を持っている。
チェーンの定義は設定ファイルによって行われているので、
そこに自作の Command クラスを追加することが可能なのである。
3. は、Servlet 2.3 に新しく追加されたインタフェースで、
Struts に限定されず、あらゆる Servlet の前処理を行う。
Filter インタフェースを実装したクラスを
web.xml の <filter> 要素に登録しておけば、
Web アプリケーションへにリクエストが到達すると、
Servlet に渡される前に 登録された Filter が実行される。
Filter はそこで自由に前処理を行うことができるし、
Servlet に処理を渡さないようにすることもできる。
Filter は、リクエストの「フック」として使えるのである。
頭の固い Servlet の処理を横取りするのに最適と言える。
Web アプリケーションの設計によって、
2 や 3 をうまく使い分けることで、
仕様の変更に強いコードを柔軟に書くことができる。
今回は、2 と 3 の方法をそれぞれ試してみよう。