JSF?Grails?Wicket?

JSFを使い続けることに不安もアリ。その一方で、GrailsとWicketも、EJB3との連携が始まっているようです。どれを抑えておくべきか、悩ましい・・。

JSFは簡単だ。

と、強がってはいるものの、やはりガチガチすぎるとも感じてます。
例えば、「データTABLEを縦ではなく横にしたい」だけなのに、異様なほどたくさんのコードとAPIを駆使しなければなりません。
案件によっては、JSFの採用を見送る場合が出てくると思う。

で、そんな中、GrailsWicketがそれぞれEJB3との統合に動き出してるという記事がありました。

Grail+EJB3のチュートリアル

Grails + EJB Domain Models Step-by-Step

将来GrailsがHibernate依存をやめてくれたら、ぜひとも使いたい組み合わせです(個人的にはHibernateは捨てたい)。

最近は コンポーネント指向Webフレームワーク ばかりが隆盛してますけど、やっぱり、URL-メソッドバインディングなフレームワークが必要なのではないかと思います。簡単で、しかもWeb・HTTPとしての自由度がある。Rails系はそういうフレームワークなんですよね。

ただ、Java6 ScriptingJRubyが盛り上がってる中、Groovyの存在意義って、持続するのか?このあたりが、もう一つの悩みどころです。

WicketとJavaEEを統合するプロジェクト

wicket-contrib-javaee

Wicketはデータ層で競合してるわけではないので、素直にJPAと連携できるとは思うのですが、なぜかわざわざこんな記事ができてました。要は、「意識してるよ!」という宣言なのかもしれません。

Wicketも悪くはないのですが、同系統なら、Clickの方が好き。サイトをみると、サンプルも豊富で、スグにでも使いたくなります。
今現在、「作りやすいもので作る」ことだけを考えると、Clickを選ぶだろうと思います。でも、マイナーなんだろうな。

やっぱり標準か?

小生、山形という、Javaの普及はこれからであろう土地で仕事をしています。プロジェクトメンバーがJava初心者10人、だとしたら、JSFで直ぐにプロジェクトを開始できるだろうか?私には自信がありません。

でもJSFの代替、どれを選ぶのが確実なのか、混沌としている。
Strutsを選んだころは、それしかなかったし、幸運にもデファクトになってくれたので良かったのですが、今はどれを選べば「5年もつ」のでしょうか。

いつ消えるかもしれないフレームワークよりは、多少苦労しても、JSFを選ぶべきか。限られたリソースで、めっちゃ効率良く、長く使えるシステムを作るには・・・

・・・う~ん・・・。


コメント

コメントしてください

closed.