Wicket を褒めてみる

Java Wicket

　ちょっと前から気になっていたもののなかなか試せず、最近になってようやく試し始めている Wicket について書いてみたいと思います。


　最近は Cubby を多く使っていた私にとって、どのへんが良いと感じたかというと。

  • 複雑な画面制御をしてもプログラムが追いやすい。Cubby の new Redirect(HogeAction.class) という書き方はなかなか良いなとは思っていたけど、比じゃない。Cubby はリンクサポートが罠だから、尚更。
  • イベントドリブンだから、どのボタンを押したらどう動くというのが書きやすい。
  • HTTP がステートレスプロトコルであることを忘れさせてくれるほど自然なライフサイクル。
  • とにかくエラーメッセージが親切。下手なことをやっても Wicket 部分で NullPointerException で落ちることはまずない。NullPointerException で落ちるのはたいてい自分のソース内だけ。
    • 間違って Wicket のモジュールに null を渡してしまったときですら「このモジュールには null は渡しちゃダメなんだよ」的な NullPointerException ではない例外がでるという親切さ。
  • テンプレートと Page オブジェクトが双方向にチェックしあってる模様。
    • たとえば Cubby でいくら Action に属性をつけても JSP で使っても使わなくても良いわけで、逆に JSP 側でなんかの属性を参照してもよっぽどヘンな書き方をしなければ怒られない。なので、下手すると属性のアンマッチにしばらく気づかないということも。Wicket ではそういうことがあまりない。
  • ほんと親切。とにかく親切。公式サイトのドキュメントはいまいちだけど（笑）。 S2Container でハマりまくった私からするとあらゆるエラーメッセージが親切過ぎてたまらない。
  • 意外にいいと思ったのは、成果物 Javadoc の作りやすさ。
    • Cubby とかだと、リクエストパラメータの Javadoc の書き方に悩む。なぜなら、テキストフィールドで入力されることを期待していても、JSP 次第でそうではなくなるから。つまり、Java のコードレベルで保証できない。JSP のメンテナンスが Javadoc にまで波及しないと悲しい目にあうわけだ。
    • そもそも、Wicket はインナークラスが増えがちだけど public になることはまずないので、public の Javadoc を優先使用ぜ！となってるときは、Wicket でかかなきゃいけない部分ってすごく少なくなるのが良い。その分、クラスや画面そのものの説明にたっぷり時間をかけることができる。この辺は、プロジェクトのドキュメンテーションの方向性で真逆になりかねないけど。


　それで、Wicket とは Guice を一緒に使っているんですが、この構成だと Cubby + S2Container （SAStruts でも Teeda でもいいんだけど）が「ぬるぬる」感じる。


　「ぬるい」ってことじゃなくて、ぬるぬるぬめぬめのぬるぬる。



　「ぬ」がゲシュタルト崩壊した人はごめんなさい。それから、あくまで感覚的な話なので分かってもらおうとも思ってません。







　ひどいエントリだ。