昨日からの続きです。もしボクがStrutsからJSFへ移行するとしたら、どんな
ことに気をつけるか？という話題でした。ポイントとしては２つあります。
1. StrutsのActionクラスを機械的にJSFのBacking Beanに置き換えない
StrutsのActionクラスはロジックを実装したもので、処理に必要なデータは
ActionForm BeanやRequest/Sessionなどの各スコープ変数から取得します。
一方のBacking Beanはイベントハンドラやバリデータといったロジック実装
も可能ですが、本質的にはUIコンポーネントのデータを保持するモデルの役割
を果たします。(ちなみにBacking BeanをManaged Beanと呼ぶこともありますが
JMXのMBeanと紛らわしいので、ボクはBacking Beanの方を使っています)
このような違いがあるために機械的にActionクラスの実装内容をBacking Bean
に移してしまうと、後になってUIコンポーネントを再利用したりする時に不都合
が生じてしまう恐れがあります。面倒ではありますが、URLのdoアクション単位
で区分けされていた処理をいったんバラして、UIコンポーネント単位の区分に
組みなおし、そのUIコンポーネントに対応させる形でBacking Beanの粒度と数
を決めていくのが良いかなと思います。
2. JSTLのロジックをJSFのJSPファイルに入れるのはなるたけ避ける
JSTLを使えば繰り返しや分岐などのロジックを簡単に実装することができます。
ですが、JSFの仕様策定においてはJSTLとの併用をフルサポートするという方針
を取っていません。また、JSTLのロジックが必要になるような場面がもしあった
としたら、そのロジックごと新たなUIコンポーネントとしてまとめてしまった方が
UIとロジックの分離という観点からもすっきりします。JSFがきちんと動作する
ためにはUIコンポーネントツリーが常に正常な状態で構築されていることが肝心
です。JSTLに限らず、通常のHTMLコンテンツの場合でもJSFとの同居を意識して
おかないと、UIコンポーネントツリーのレンダリングの順番などによって、意図
していない表示結果になったりすることがあります。(一般的には素のHTMLコンテ
ンツは
以外の「異物」はJSPファイル上に混入させないようにした方がトラブルは少ない
ように思います。
3. 一回の処理の中でデータをRequestスコープで引き回さない
Strutsの場合にはサブミット時に結果表示させたいデータをActionクラス内で
Requestスコープにセットしておき、結果表示するJSPファイルでそれを参照す
るということは良く行われるかと思います。ですが、JSFの場合には表示したい
データはいずれかのUIコンポーネントのデータであるはずで、そのデータは
Backing Beanに格納されているはずです。ですので、基本的にはRequest
スコープでデータを引き回すということはあまり行わないで済むはずです。
Strutsの慣習をそのま持ち込んでRequestスコープを多用してしまうと、処理
の流れとUIコンポーネントのモデル構造が密接に絡み合ってしまってメンテ製
が著しく低下してしまいます。
パッと思いつくところは以上の３点です。1.などは結構な手間になってしまい
ますので、大規模なStrutsアプリケーションの場合にはJSFへきちんと移行
するのはあまり現実的ではないかも知れません。
