以Play 2.1为后端构建AngularJS客户端代码的好方法
我拥有一个Play 2.1应用程序。
最初，我使用Play 2.1的默认模板机制，直到我学习了AngularJS。
现在，我显然希望我的客户端成为AngularJS应用程序。
但是，在浏览网页时，我发现没有明确的方法来实现它：
让Play扮演一个简单的RESTful应用程序（删除view文件夹）并制作一个完全不同的项目来构建视图（由grunt.js初始化的AngularJS应用程序）。
优势：可能不那么杂乱，前后端团队可以轻松分开工作。 缺点：需要AngularJS应用程序的另一个HTTP服务器。
尝试将AngularJS应用与传统Play的工作流完全整合。
缺点：对于像AngularJS这样非常复杂的框架，它会导致模板管理混乱，例如：scala.html（用于Play）/ tpl.html（用于Angular）... =>凌乱。
在播放项目中制作一个自定义文件夹，但与Play脚手架创建的初始文件夹不同。 例如，我们将其myangularview而不是传统view 。 然后，将由grunt.js生成的静态内容发布到Play的public文件夹中，以便通过Play的路由从浏览器访问。
优点：组件之间的SRP仍然得到相当的尊重，不需要像1中那样为客户端使用另一个轻型HTTP服务器。
我指出了我自己的优点和缺点。
什么是实现Play with Angular组合的好方法？
是的，我正在回答我自己的问题:)
我遇到了这样的做法：http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails的？ 无论框架是什么，需求仍然完全相同。
它主张在API（后端）和前端（在这种情况下对后端服务器进行AJAX调用）之间进行真正的分离。
因此，我所学到的是：
public文件夹，旨在为静态内容提供服务：HTML，角模板（例如），CSS等等...优势？ =>处理一个唯一的服务服务器的API展览以及UI的静态资产。 通过这个组织，像Yeoman这样的工具将能够为开发者带来一些非常棒的方便的东西，例如livereload功能。 :) :)
当然，在开发阶段，我们最终会得到两个不同的域（例如localhost：3000和localhost：9000），从而导致传统ajax请求出现问题。 然后，正如文章指出的那样，代理可能非常有用。
我真的觉得这整个练习非常优雅和愉快的工作。
几天前关于前端堆栈/解决方案的一个有趣的讨论就是关于前端堆栈/解决方案，可能是其中的一些内容，有些人似乎使用了角度：https：//groups.google.com/forum/# ！Searchin的/播放的框架/前端/播放框架/ IKdOowvRH0s / tQsD9zp - 5oJ
链接地址: http://www.djcxy.com/p/74287.html上一篇: A good way to structure AngularJS client code with Play 2.1 as backend