yojikのlog

yojikのブログです

Strutsも捨てたモンじゃないなーと思った

事情により苦手なStrutsを調べているのだけど、Strutsにプラグインする下記のフレームワークがイイ感じ。知ってる人には今更かもしれない。
Struts Dialogs
Strutsのこのパターンを実装したフレームワークらしい。
例えばこのフレームワークで、Customerを検索して一覧を出力、選択して詳細画面に飛んで、編集してサブミットする、といった連続的な処理を実装する場合は、以下の要素で一連の処理を構成する。

  • CustomerForm(処理で利用するデータをセッションスコープで保持)
  • InputCustomerAction(一連の処理中のサブミットをすべて処理)
  • RenderCustomerAction(一連の処理中の表示をすべて担当)
  • 複数のJSPビュー

まずRenderActionに複数のViewを表示する責務を持たせる。どのViewを表示するかはRenderActionからのForwardで決める。
ユーザ入力はすべてInputActionで処理してからRenderActionにリダイレクトする感じ。このとき引継ぎ情報はセッションスコープのActionFormにすべて突っ込む。ついでに処理後にRenderActionに表示させたいViewの名前をActionFormに突っ込んでおく。RenderActionはこの情報を元にフォワード先を決める。*1
ちなみに、この時点でPRGパターンも自然に実装されてることになる。
これだけで、かなり楽にステート管理ができるようになる。なかなかシンプルだと思う。ローテクで最大限の効果を発揮してるところがすごい。しかも設定ファイルの記述項目がシンプルになり凝集度が増す感じ(サンプル参照のこと)。
サンプルはこちら。ウィザードの途中で、全然関係ないページを見てから戻ったりしても、きちんと状態が残っている!
前述のパターンにはこんな感じのことが書いてある。

Remember, the primary object in a web application is a web resource, not a page. A page is just a view; one web resource can have several views. Do not build application around pages, build it around web resources.

Webアプリで重要なオブジェクトは、ページじゃなくWebリソース*2とのこと。この考え方は、単純なページ指向より未来を見据えていて、かなり面白そう。分析の仕方とかにも影響あるはず。

*1:個人的にはリクエストデータに画面名含めたほうが、クリーンなURLになっていい気もする

*2:厳密な定義があれなんだけど、一連の処理で主題にしているオブジェクト( or ステートマシン)たいなイメージ?