7

Play 2.1 アプリケーションを所有しています。

最初は、AngularJS を学ぶまで、Play 2.1 のデフォルトのテンプレート メカニズムを使用していました。

ここで、クライアント側を AngularJS アプリにしたいのは明らかです。

ただし、ネットサーフィンをしているときに、それを達成する明確な方法がないことがわかりました。

  1. Play を単純な RESTful アプリケーションとして動作させ (viewフォルダーを削除)、ビューを構築するためのまったく別のプロジェクトを作成します (grunt.js によって初期化された AngularJS アプリ)。
    利点: 煩わしさが減り、フロントエンド チームとバックエンド チームが別々に作業しやすくなります。欠点: AngularJS アプリ用に別の HTTP サーバーが必要です。

  2. AngularJS アプリを従来の Play のワークフローに完全に統合してみてください。
    欠点: AngularJS のような非常に複雑なフレームワークでは、テンプレート管理の混乱につながります。たとえば、scala.html (Play の場合) / tpl.html (Angular の場合) ... => 面倒です。

  3. Play プロジェクト内にカスタム フォルダーを作成しますが、Play スキャフォールディングによって作成された初期フォルダーとは異なります。たとえばmyangularview、従来の代わりにそれを呼びましょう。view次に、grunt.js によって生成された静的コンテンツを Play のpublicフォルダーに公開して、Play のルーティングを介してブラウザーからアクセスできるようにします。
    利点: コンポーネント間の SRP は依然としてかなり尊重されており、1 のようにクライアント側に別の軽量 HTTP サーバーを使用する必要はありません。

長所と短所について私なりの見解を述べました。

Play と Angular の組み合わせを実現するにはどうすればよいでしょうか?

4

2 に答える 2

3

はい、私は自分の質問に答えています:)

私はこのやり方に出くわしました: http://jeff.konowit.ch/posts/yeoman-rails-angular/

レール?? フレームワークに関係なく、ニーズはまったく同じです。

API (バックエンド側) とフロントエンド側 (この場合はバックエンド サーバーへの AJAX 呼び出しを行う) を実際に分離することを提唱しています。

したがって、私が学んだことは次のとおりです。

  • 開発段階では、開発者は 2 つのサーバー (2 つの異なるポート上の localhost) を使用します。
  • 生産段階では、フロントエンド要素はバックエンド側全体に含まれます (この記事では、publicHTML、Angular テンプレート (たとえば)、CSS などの静的コンテンツを提供することを目的とした種類のフォルダーを扱います...利点? = > 唯一無二のサービング サーバーの API の説明と UI の静的アセットを扱います。

この組織により、Yeoman のようなツールは、例えばlivereload機能のような非常に便利な機能を開発者にもたらすことができます。:):)

もちろん、開発段階では、2 つの異なるドメイン (たとえば、localhost:3000 と localhost:9000) が作成され、従来の ajax リクエストで問題が発生します。次に、この記事で指摘されているように、プロキシが非常に役立つ可能性があります。

このプラクティス全体が非常にエレガントで快適に作業できると本当に思います。

于 2013-09-22T20:06:01.513 に答える
1

数日前に play メーリングリストで frontend-stack/solution について興味深い議論がありました。あなたにとって何かがあるかもしれません。かなりの数の人々が angular を使用しているようです: https://groups.google.com/forum/# !searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ

于 2013-09-19T13:52:18.950 に答える