今回のプロジェクト、実はフレームワークとして、Click を使っています。
使い勝手は...正直微妙です。 試行錯誤の結果、Click の持っている
機能をあまり使わないで、自分たちでいろんなものを作り込む方向に
倒さざるをえなかったので、それなりに手間がかかる印象。
ソースコードがシンプルなので、色々と手は入れやすいですが、どうもかゆいところに
手が届かないところが多く、かゆいところに手を届かせるためには、結構
自分で頑張らないといけないという印象。
粒度の大きいUIコンポーネントは結果のHTMLがどうなるか想像しづらいために
プログラマが混乱してしまったみたいなので、
結局 Velocity で HTML をたくさん書く方がうまくプロジェクトが回ったりとか、
Validationも微妙に要件に会わなくて結局自作したりとか、
まぁそういった部分です。
最近思うのは、JavaのWebアプリケーションフレームワークは以下の3つのことができれば
OKで、それ以上の機能は冗長なのではないか、ということです。
1. HTTPリクエストをJavaオブジェクトに変換する
2. リクエストURLから、呼び出すメソッドを特定し、実行する。
3. 処理結果をHTMLに変換する。
上記 3ステップがなるべく楽にできるのが、良い Web アプリケーションフレームワーク
なのではないかと。Servlet + JSPも上記の3ステップをそれなりにサポートする
フレームワークではあるのですが、いまいち面倒臭い部分が多いために、
その他もろもろのフレームワークが必要になってくるのではないかと思うのです。
使い勝手は...正直微妙です。 試行錯誤の結果、Click の持っている
機能をあまり使わないで、自分たちでいろんなものを作り込む方向に
倒さざるをえなかったので、それなりに手間がかかる印象。
ソースコードがシンプルなので、色々と手は入れやすいですが、どうもかゆいところに
手が届かないところが多く、かゆいところに手を届かせるためには、結構
自分で頑張らないといけないという印象。
粒度の大きいUIコンポーネントは結果のHTMLがどうなるか想像しづらいために
プログラマが混乱してしまったみたいなので、
結局 Velocity で HTML をたくさん書く方がうまくプロジェクトが回ったりとか、
Validationも微妙に要件に会わなくて結局自作したりとか、
まぁそういった部分です。
最近思うのは、JavaのWebアプリケーションフレームワークは以下の3つのことができれば
OKで、それ以上の機能は冗長なのではないか、ということです。
1. HTTPリクエストをJavaオブジェクトに変換する
2. リクエストURLから、呼び出すメソッドを特定し、実行する。
3. 処理結果をHTMLに変換する。
上記 3ステップがなるべく楽にできるのが、良い Web アプリケーションフレームワーク
なのではないかと。Servlet + JSPも上記の3ステップをそれなりにサポートする
フレームワークではあるのですが、いまいち面倒臭い部分が多いために、
その他もろもろのフレームワークが必要になってくるのではないかと思うのです。
ちなみに個人的にはCubbyがおすすめです。
http://cubby.sandbox.seasar.org/
もちろん良いところも多々あります。
設定ファイルの記述量はStrutsに比べて
圧倒的に少ないですし。
今後に期待しています。
Cubby、ちらっとみましたが、おもしろそうですね。最近はこういうコンパクトな
フレームワークが流行りなのでしょうか。
Seam とかも話題なので、そうでもないか。