Wicket でこんな風にプロジェクトをすすめました

　ちょっとした成功体験を紹介します。

どんなプロジェクトだったか

　オフコン系の社内業務支援システムをWebベースに作り変えるプロジェクトでした。まだ全部終わってませんので過去形でいうのは適当ではありませんが。

コンポーネントの登録を省力化した

　とにかくこの手のシステムは1画面あたりの項目数が多い。なので、コンポーネントの生成と登録をちんたら手組しているとラチがあきません。そこで私がとった方法は、Excelシートに項目名とコンポーネントの種類、Wicket ID、必須か否かや値の範囲などの簡単なバリデーション情報を書いて、それを POI で読み込んでソースを生成することでした。

　はじめはコンポーネントの種類はまさしくクラス名で指定していたのですが、何度かバージョンアップを繰り替えして今では和名で指定しています。実際のクラス名とは別区XMLファイルで結びつけています。たとえば「テキストフィールド」と指定されたら TextField クラスを使うといった感じです。

　生成するソースはページクラスではなく、MarkupWebContainer のサブクラスです（このプロジェクトではこれをワーキングペインと読んでいます）。ページクラスにこれをそのまま add して使ってもらいます。これに CompoundPropertyModel をむすびつけます（永続化には S2JDBC を使用しました）。すべてのコンポーネントは Wicket ID と同じ名前のメソッドで取得できるようにしました。たとえば、Wicket ID が hoge という RadioGroup コンポーネントの下にぶら下がっている fuga という Radio コンポーネントを取得するには以下のようにします。

String s = workingPane.hoge().fuga().getModelObject(); // モデルオブジェクト取得

独自コンポーネントを充実させた

　前述の仕様をまとめていると、どんな UI コンポーネントが必要かが自ずから分かってきます。つまり、どんなビヘイビアを使うのかとか、どんなコンバータを使うのかとかです。こういうものは惜しげもなく新コンポーネントとして作ってしまいます。無名クラス（LinkとかButtonを利用する際に作りがちですよね）を作ったら負けぐらいの勢いで作っていきます。これによってさらに前述の Excel シートが書きやすくなります。

スーパークラスを充実させた

　社内向の業務システム、特にオフコン、汎用機系を踏襲したようなものはとにかく画面がパターン化されています。そのため、スーパークラスを充実させるとかなりコーディングが楽になりました。たとえば、このプロジェクトも業務システムによくあるように画面下部にファンクションキーに対応するボタンがならんでいるのですが、ファンクションキーの F3 に対応するボタンが押されたら実行されるイベントは以下のように書けるようにしました。

@Override
protected void onSubmitF3() {
    // 処理
}

　また、画面によってボタンのラベルや有効化/無効化の設定は以下のように書けるようにしました。

f3().enabled(true);
f3().setLabel("実行");

まとめ

　今回のプロジェクトは、俗に言う「SE」的なポジションの人がいなかったように思えます。いるのは、仕様をよく知っている（仕様の決定権のある）プログラマ（ただし、Wicket はもちろん Java のコーディング力が特別高いわけではない）と比較的 Wicket を自在に扱える私のような（しかし仕様はよくわからない）人でした。そして、プログラマが「ここよく使うんだけどもっと簡単にならない？」というのを頻繁に挙げてくれて、それを私がフレームワーク化していくというような流れで開発していきました。

　Wicket はよく Web プログラミングにオブジェクト指向を取り戻したと言われますが、私もそう思います。この Wicket の特徴のおかげでこのやりかたでうまく流れたのかなと思います。