Java Webフレームワークを今選択していますか？
カスタム開発のmvcフレームワーク上に構築された大規模なWebサイトを、Ajax、リッチメディアコンテンツ、マッシュアップ、テンプレートベースのレイアウトの組み込みサポートを提供するJavaベースのWebフレームワークに移行する計画段階です。 、検証、最大のhtml/Javaコード分離。 Grailsは良い選択のように見えましたが、スクリプト言語を使用したくありません。 Javaの使用を継続したい。テンプレートベースのレイアウトは、機能が似ているが外観が根本的に異なる複数のWebサイトでこのWebアプリケーションを使用するための主要な関心事です。
ポータルベースのソリューションはこの問題に適していますか？
「Spring Roo」または「Play」の使用に関する洞察は非常に役立ちます。
this のような類似の投稿を見つけましたが、1年以上前のものです。物事はその間に確実に変化しました！
EDIT 1：すばらしい回答をありがとう！このサイトは、インザトレンチプログラマー情報の最良の単一ソースになりつつあります。ただし、portal-cms duoの使用に関する詳細情報を期待していました。ヤヒアは商品に見えます。同様の何か？
ポータルベースのソリューションはこの問題に適していますか？
個人的に、私は大きな脂肪のポータルソリューション（多くの場合、生産性を低下させるもの）には近づかないでしょう。 Gatein については良いことを聞いたことがありますが、実際の経験はありません。
「Spring Roo」または「Play」の使用に関する洞察は非常に役立ちます。
Spring Rooについて、 Spring roo Vs（Wicket and Spring） などの以前の回答をインターネットで読んだことがありますが、私はまだ納得していません（たぶんわかりません）。 「その成熟度は定かではありませんが、もっと重要なのは、SpringSourceがGrailsとRooで何をしているのか、本当に疑問に思っていることです（いいえ、 Grails vs Roo-SpringSourceが2つの非常によく似たテクノロジーを推進しているのはなぜですか？ はありません彼らが両方とも生き残ることを私に納得させないでください）。
Playについてはあまり言えません。私はみんなと同じようにデモを見てきましたが、実際のフィードバックを読みたいです。それまで、私は待ちます。
同様の投稿を見つけました（...）。物事はその間に確実に変化しました！
はい、いいえ:)しかし、プレゼンテーションフレームワークの地獄に入りましょう。1年前のように、あなたの質問に対する単一の答えはありません。そこにはたくさんのフレームワークがあり、明確な勝者はいません。ほんの少し引用するだけです。
- JSF：このコンポーネントベースのフレームワークについては懐疑的な人がたくさんいます。私も含めて、私はそれについて話すのがベストではありませんが...
- JSF 2（+ CDI/Weld）：JSF懐疑論者は（「 by Gavin King ）」「再確認」することをお勧めします。実際、JSF 2は、特にCDIを使用した場合の大きな改善であると思いますが、それでもまだかなり新しいものです（理解して、フィーバックがありません）。 Java EE 6を採用する場合は、チェックしてください。
- Wicket：別のコンポーネントベースのフレームワークが注目を集めています。私はそれについてほとんど良いことを聞きます：JSFよりシンプル、ニースデザイン、高いテスト容易性、HTMLデザイナーフレンドリーなど。あなたはそれを好きかもしれません。
- Tapestry：しないでください（ なぜTapestryの使用をやめたのですか？
- Struts 2、Spring MVC、Stripes：アクションベースのフレームワーク。 すべてがまともで、あなたのニーズをカバーします（個人的には、Stripesとその構成上の慣習が好きです Stripes vs. Struts2 それのアイデアを得るために）。
- GWT、Flex、Grails：これらはあなたが探しているものではないかもしれません。 FlexとGWTの（最近のバージョン）についてはあまり話せませんが、Grailsは havesomefans を実行することを知っています。
実際、Matt Raibleの プレゼンテーション を見てみることをお勧めします。彼はWebフレームワークの比較、その長所と短所の表示、事実と数字の収集、傾向の表示で本当に素晴らしい仕事をしました。お勧め：
- JSF、Spring MVC、Stripes、Struts 2、Tapestry、Wicketの比較 （まだ廃止されていません）
- 将来のWebフレームワーク：Flex、GWT、Rails、Grails （代替手段を味わうためだけに）
- キックアスWebフレームワークの比較 （これは最新のものです）
本当に、これらのプレゼンテーションを見てください。適切なフレームワークを見つけるのに役立ちます（一意の答えはありませんが、排除することで選択を制限できます）。
私はSpring 3とJqueryをしばらく使用していましたが、Playについて聞いて、試してみました。 PlayはPHPのようなものと、SpringのようなヘビーデューティーJavaのフレームワークの間にぴったりです。
プレイで一番好きなことは次のとおりです。
- Playアプリケーションを非常に簡単に作成できるので、Springを使用して画面上に簡単なcrudアプリケーションを作成するために、コーディングと設定をかなり行う必要があります（ただし、Spring 3によって非常に簡単になりました）。
- Spring Securityは素晴らしいですが、複雑さが犠牲になります。 Playのセキュリティモジュールは非常にシンプルで、おそらく90％のアプリケーションのニーズに対応しています。
- サーブレットベースのフレームワークですべての再デプロイを行う代わりに、ブラウザでコードを変更してリフレッシュを実行すると、PHPのような変更を確認できます。
- エラーメッセージはきれいに表示され、ほとんどの場合、わかりにくいものではありません。 Playはまだエラー処理に取り組む必要があります
- Playには非常にシンプルなプラグインメカニズムがあります。
- オブジェクトの永続化は、メモリ内のデータベースとJPAがフレームワークに付属しているため、外部オブジェクトの永続化ツールの構成がないという点で非常にうまく行われます。メモリ内データベースから実際のRDBMSに移行することは、構成ファイルの1行の変更です。
- MVCのセットアップは非常にうまく行われています。ドメインオブジェクトを作成するために拡張するModelクラスは、JPAエンティティマネージャーと統合されます。 POJOだけではありません。
- URLのコントローラへのマッピングはシンプルで柔軟であり、すべて1つの「ルート」ファイルに含まれています。
- プロジェクトを作成すると、Playはすべてのjar依存関係を処理し、PlayにはEclipse-ify（または好きなIDE）ユーティリティがあり、お気に入りのIDEに直接インポートします。
Playが気に入らないこと
- ドキュメントはまだそこまでありませんが、ドキュメント化されていない機能がまだたくさんあります。
- フレームワークはサーバーなので、ポートを各アプリケーション専用にする必要があります。私は誰かが仮想ホストプラグインに取り組んでいると思いますが、実際にはまだ動作していません。
- それは若く、プロジェクトは素晴らしく、技術は素晴らしかったが、本当にもっと多くの開発者が必要だ。少し時間を割いてみたいと思います。
私の一番の選択は Wicket です。マークアップとJavaコードの明確な分離。コンポーネントの作成と使用は非常に簡単です。使いやすいAjax、テスト容易性。ページ/コンポーネントを直接デバッグでき、JSF実装から不可解なエラーメッセージを取得しません;）
また、優れた比較ウィケット<-> JSF in terms of performance
私にとっての上位3つの選択肢は（アルファベット順）です。
彼ら：
- 優れたajaxサポートを持っている
- アプリケーション（GWTなど）ではなく、実際のWebサイトを作成できます。
- 安定した、十分に文書化された、広く使用されている
- MVC
- 純粋なJava
- ミドルウェアとしてのSpringとの簡単な統合
Playは、JavaのRORバージョンであるRORによく似ています
他の回答とは対照的に、人気のあるWebフレームワークの欠点（IMHO）を強調したいと思います。
JSF2-リリース済みで既にエージングされています。まだ少数のニュース/記事/ブログ投稿/経験だけが出ています。私は懐疑的です。 jsf 2を完全にサポートするRichfaces/Icefacesの次のメジャーリリースを待っています-現在、ダウンロードできるのはアルファビルドのみです。
Struts 2-まだ支柱に依存していて、コードの大部分をリファクタリングしたい場合にのみ良いことのようです。そうでなければ：しないでください。
GWT-単一ページおよびJava-> javascriptアプローチが好きではありません。 1つのセッション-複数のビュー/ウィンドウを簡単に実現できるかどうかはわかりません。私にとって、このフレームワークは、大規模なユーザーのシングルウィンドウリッチインターネットアプリケーションに使用する必要があります。
Wicket-良いアプローチですが、少し冗長で利用可能なドキュメントが少なすぎます（アクションブックの優れた改札を除きますが、これは1.3のみを対象としています）。また、私にとっては、その上に構築される大きなプロジェクトが不足しています。そして、現在、改札の道がどこを進んでいるのか、あるいはすでに行き止まりに追い込まれているのかを見ることができません。
Spring MVC-まだ試していませんでしたが、このフレームワークを適切に使用するには、クラスパスに多くのjar（春の混乱）を含める必要があります。そして、それはJSP（ほとんどのプロジェクト）に依存しています。そして、純粋なMVCフレームワークのみを取得します。他のすべてのもの（ajaxなど）を実装/統合する必要があります。
Stripes-小さくて素敵なMVCフレームワークですが、ドキュメントが少なすぎ、コミット/コミッターが少なすぎ、リリースが少なすぎ、業界サポートが少なすぎ、メーリングリストのアクティビティが少なすぎます。
私はまた、あなたにとって（そして私にとっても）オプションとなるかもしれない主要なフレームワークを見逃した（Tapestryを意図的に残した）ことにも興味があります。
JAX-RSで大成功を収めました。ある種のJSR仕様と、サーブレットとポートレットの仕様以外の複数の実装を持つ唯一のJava Webフレームワークです（これは悪いことです）。
Javaの長所と短所の1つは、フレームワークを選択して一致させることができることです（Pythonにもこの機能/問題があります）。すべての卵を1つのバスケットに入れる必要がないので、すてきです。
一般的なJava Webアプリケーションスタックレシピは次のとおりです。
Javascript/Flash +要求/応答処理+依存性注入+永続性
Javascript： JQuery、Prototype、Dojo
リクエスト/レスポンス： Spring MVC、ストライプ、および私のお気に入りのJAX-RS（ジャージー、Apache CXF）
依存性注入： Spring、Guice
永続性： JPA（Hibernate、Google Appストレージ）、Hibernate、JDOなど。
また、AspectJを使用してJavaの「吸い込みを少なく」することに大きな成功を収めました。 Springの@ConfigurableおよびAspectJのITDミックスインを使用すると、DomainオブジェクトのようなRailsを取得できます（これは、Rooが実際に行うことですが、これを行うためにRooは必要ありません）。
RESThub をご覧ください。Playと同じ原則に従っています！ただし、Maven 3/Spring 3/Jersey/jQueryなどのエンタープライズグレードのフレームワーク/ツールを再利用することで実装されています。
RESThubは完全なスタックツールキットであるため、サーバーサイドMVCまたはサーブレットベースのframworksがないため、他のフレームワークと比較して非常に破壊的です。代わりに、JAX-RS（REST）WebサービスとembeddedJに基づくJavascriptテンプレートシステムを使用するjQuery UIベースのGUIを使用します。
サーバーはステートレスであり、HTML5 sessionStorageを使用してクライアント側でセッションを維持します。このアプローチは、RIAとスケーラビリティのための設計です。
一部のデモアプリケーションが提供されています（作成中であっても）。
JSFは素晴らしいフレームワークですが、JSF 1.2はリリースから長年にわたってビジョンを欠いていました。 JSF 2.0は有望に見え、ajaxサポート、facelet、注釈サポート、デフォルトの規則（XMLが少ない）、1.2より簡単なコンポーネント構築など、JSF 1.2から多くの新しいものが追加されています。
DIサポートが必要な場合は、Springとも統合します。
私は春の勧告を二番目にします。私は大ファンのGWTではありません。Java-> Javascriptクロスコンパイラーはまだそこにあるとは思いません。私はサーバーでspringとクライアントでjQueryを使用するAJAXアプリで作業しています。技術的には「すぐに使える」jQueryのサポートはありませんが、spring-MVC AjaxViewの実装は非常に簡単で、約25行のコードが必要です。
ショーに少し遅れるかもしれませんが、私は Vaadin に言及するために、haveを持っています。プログラミングは、コンポーネントベースのアプローチで、Javaのみで行われます。クライアントとサーバー間の通信は、データ転送よりもユーザーとの対話に重点を置いており、すべてのビジネスロジックはサーバー上にあります。
数年前はポータルソフトウェア「Backbase」を使用していましたが、これはそれほど成熟していませんでした。しかし、開発には優れていて簡単でした。
あなたが探しているのはヤヒアに近いものだと思います。 GWT、マッシュアップ、メディアコンテンツなどをサポートしています。
http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templateshttp://www.jahia.net/downloads/jahia/jahia6.0.0/ readme/index.html
ItsNat をご覧ください
ItsNatは基本的にサーバーのJava W3Cブラウザーであり、驚くほどシンプル（サーバーのDHTML）であり、AJAX集約型 シングルページインターフェイス アプリケーションを促進します
Ext GWT + Spring
単なる弾丸以上のものに値するものは、プレイヤーベースのRIAフレームワークです。例Adobe Flex + Java（もちろん、これは「サイト」が本当に「サイト」であるか「アプリケーション」のようなものであるかによって多少異なります。Flexでブログサイトを作成することはありません。）
アヤックス、
AJAX-as-a-buzzwordの意味では、Flexは通常AMF（AJAXアプリで使用されるプロトコルよりも、より効率的のバイナリプロトコル）を使用しますが、厳密にはAJAX Flexも含まれています。そのため、FlexはAJAXをサポートしていますが、「AJAXよりも優れています」もサポートしています。
リッチメディアコンテンツ、マッシュアップ、
FlexがFlashの「仮想マシン」プラットフォームで実行されるため、追加する必要はほとんどないと思います。
テンプレートベースのレイアウト、
これが正確に何を達成しているかはわかりませんが、Flex mxmlのように聞こえます。
検証、
もちろんサポートされていますが、空想を取りたい場合は、カスタムのものを作成することもできます。 （そうする必要はありません。）良いことは、あなたが望むだけ洗練されたものにできることです。
最大のHTML/Javaコード分離
Flex/Silverlight/JavaFXのような「仮想マシン」開発アプローチを使用しても、これ以上分離することはできません。これにより、サーバー側のロジックおよびデータアクセスレイヤーからプレゼンテーションコードを分離できるようになるだけでなく、それらが分離されることを保証できます。開発環境を「仮想化」することで、ブラウザー間の互換性、一貫性のあるターゲットプラットフォーム、アプリケーションを壊す新しいブラウザーや新しいブラウザーのリリースの心配、最高レベルのJavaのようなデバッグ機能、よりプロフェッショナルで印象的な最終製品が得られます。