Play Framework 1.0と2.0の主な違いは何ですか？
Play Framework 2.0の最近のリリースでは、Play Framework 1と2の主な違いを高レベルの観点から要約できる人がいるかどうかを知りたいと思います。
私はすでにいくつかをコンパイルしました（1.0をプレイ-> 2.0をプレイ）：
- テンプレートエンジン：Groovyページ-> Scalaテンプレート
- パーシスタンス：Hibernate-> Ebean
- 言語サポート：Java-> Scala、Java
- 動的コンパイル：バイトコードインジェクション-> SBTによる動的コンパイル
- ビルドシステム：n/a-> SBT
- 拡張性：モジュール、プラグイン->サブプロジェクト、プラグイン、SBTプラグイン
ほかに何か ？アッカ？
もちろんこれが私のリストですが、重複があります
下位互換性が失われます（ゼロからの書き換えです）
コアはscala vs vs Java（学んだらscala共同作業する）
テンプレート用のscala（ただし、移行を容易にするために、作業はモジュールとしてgroovyテンプレートで行われています）。したがって、各パラメーターのタイプを指定する必要があります。
pythonスクリプトの代わりにsbtコンソール
組み込みソリューションの代わりに依存関係を解決するためのsbt（依存関係の再生コマンド）
モジュールの可用性、すべてを移行するには明らかに時間がかかります...
javaの場合、休止状態の代わりにebeanを優先します（ただし、休止状態を使用できます）
scalaの場合、anormが付属しています（ただし、他のライブラリを使用することはできます）
よりモジュール化され、他のコンポーネントを選択しやすく
型の安全性の向上-コンパイル時にビューとルートさえチェックされます
よりよい性能
タイプセーフサポート、それは typesafeスタック の一部です
マジックは少なく、バイトコード生成などはそれほど多くない
より標準的な（playプロジェクトは単なる標準のsbtプロジェクトです）
別のコントローラーAPI（詳細、IMHO） シンプルプレイ1.xクラッドコントローラー を と比較できます2.0を1つ再生します
scalaはファーストクラスの市民ですが、Javaは同等にサポートされています（それぞれにネイティブAPIがあります）
ホット再コンパイルは遅いです（それはまだベータ版です、彼らがそれを解決することを望みましょう）
scala IDEサポートはJavaほど成熟していません（しかし、それはうまく進化しています）
akkaに委任された非同期サポート
nosql dbsのような、さまざまな種類のデータソースに対してより適切に準備
詳細については、 play 2.0のページ をご覧ください（スペイン語の翻訳あり こちら ））および RC1ドキュメント
とにかく、私は主な違いは、play 1.xがj2eeからエスケープしながら独自のスタックを構築しようとしたことであると思いますタイプセーフのように...
次の点が重要だと思います。一部は賛成であり、いくつかは反対です。あなたは自分で自分の好みのバージョンを確認する必要があります。
コアはScalaで書かれているので、Scala開発者でないと、自分でバグを簡単に修正することはできません。これは1.2の強みでした。さらに、ドキュメントが非常に良いです。失われました。play1.2では、コードを簡単に調べることができます。Eclipseでは、IDEで参照を簡単に検索できます。同等のものが存在するかどうかわかりませんIDE Scalaの場合。EclipseintellijはScalaで問題なく動作すると聞きましたが、独自の経験はありません。
2.0では、コンポーネントの結合が緩くなっています。 Play 2.0では、好みのテンプレートエンジンまたは永続化レイヤーを簡単に選択できます。 1.2では、永続化のためにJPA以外のものを選択することがより困難でした。
Scalaはファーストクラスの市民になりました。したがって、アプリケーションをScalaまたはJavaで記述したい場合は自由に選択できます。
他のフレームワークへの依存度は高くなっています。たとえば、今ではScalaとAkkaが必要です。どちらも素晴らしいですが複雑です。そのため、これらのフレームワークの1つにエラーがあると、大きな問題が発生する可能性があります。play1.2では、そのようなリスクしか見られません。 Hibernateの場合。
「すべて」がタイプセーフになり、コンパイラで確認できるようになりました。
PythonをSBTに変更すると、開発マシンにさらに多くのメモリが必要になります。つまり、Scalaコンパイラには少なくとも512 MBのRAMが必要です。これは、継続的ビルドサーバーでの問題。
もちろん、Codemwnciで言及されているように、細かい点はたくさんあります。
あなたのリストは非常に良いスタートです。私のリストはいくつかの追加機能で似ています。
- テンプレートはGroovyからScalaに移動しました。
- Scalaがオプションのプラグインではなく、ファーストクラスの市民になる
- 特にテンプレートで、タイプセーフに重点を置く
- PythonからSBT
- Ebeanへの休止
- モジュールとしてのAkkaではなく、Play 1.xの非同期機能を補足するAkka
- コアで利用可能なAnorm（scalaプラグインではなく））
- 動的要素が少なく、コンパイルが多いため、生産におけるパフォーマンスが向上
- TypeSafeスタックに統合
予想通り、リストには重複があります。また、このリストは2011年11月現在のものであり、play 2はまだベータ版です。
ここに非常に良い答えがいくつかあります。私は、いくつかの小さな点を追加し、時間とともに明らかになる詳細を提供したかっただけです。
In-Browser-Reporting：ブラウザのJavascript（Googleのクロージャコンパイラを使用）およびCSSファイルのエラーに関する2つのレポートを再生し、Java /だけでなくScalaファイル。これは本当にクールです。
WARとしての展開：Play 2 まだ公式には行われていません WARとしての展開またはエクスポートをサポートします。そのようなサポートを提供することになっている plug-in が存在しますが、いくつかの既知の問題があるベータ版です。すべてのPlay 2機能を完全にサポートすることは、サーブレット3.1コンテナなしでは実際には不可能です。これには少なくとも半年、おそらくそれ以上かかるでしょう。
プラグイン：現時点では、play 1にはまだまだたくさんあります。プラグインに依存している場合は、play 2に存在することを確認してください同じように。
IDEサポート：IntelliJ 12には、play 2のサポートが組み込まれているはずです。すでにEAPを取得できます（許可されたハイパーリンクが不足しているため、グーグルする必要があります）。
主観的意見：Play 2は、より高度な機能とより完全なタイプセーフをサポートするために単純さを犠牲にしたかのように感じます。 Play 2が難しい、または直感的でないと言っているのではなく、Play 1ほどではありません。
Play 1は、Web開発者によるWeb開発者向けのWebフレームワークでした。 Play 2は、Web開発者によるWeb開発者向けの将来を見据えたWebフレームワークです。
つまり、フォーカスに若干のシフトがあり、使いやすさはもはや主要な目標ではなく、2つの主要な目標の1つです。これはもちろん私の意見に過ぎず、私はほとんど知りません。
このトピックに関する別の見解は、次のブログ投稿にあります。 http://blog.awfbeat.com/post/22314115684/impressions-of-play-framework-1-2-4-vs-2-
this の記事から要約すると：
- Google Closure Compiler、CoffeScript、LESSを直接使用するためのアセットパイプライン
- ルートファイルも含めてすべてがコンパイルされます
- 実行中のアプリのメモリフットプリントが少ない
- Iteratee/Enumeratorによる非同期/反応型プログラミング
- あなたが言ったように、Scala、Akka、...