最初,我使用了Play 2.1中的默认模板机制,直到我…学习了AngularJS.
现在,我显然希望我的客户端成为AngularJS应用程序.
然而,在网上冲浪时,我发现没有明确的方法来实现它：
>让Play表现为一个简单的RESTful应用程序(删除视图文件夹)并创建一个完全不同的项目来构建视图(由grunt.js初始化的AngularJS应用程序).
优势：可能不那么混乱,前端和后端团队可以轻松地分开工作.
缺点：AngularJS应用需要另一个HTTP服务器.
>尝试将AngularJS应用程序与传统的Play工作流程完全集成.
缺点：使用像AngularJS这样非常复杂的框架,会导致模板管理混乱,例如：scala.html(对于Play)/ tpl.html(对于Angular)… =>乱.
>在播放项目中创建自定义文件夹,但与Play脚手架创建的初始文件夹不同.我们称之为myangularview而不是传统视图.然后,将grunt.js生成的静态内容发布到Play的公共文件夹中,以便通过Play的路由从浏览器访问.
优点：组件之间的SRP仍然得到了相当的尊重,并且不需要像1中那样为客户端使用另一个轻型HTTP服务器.
我指出了自己对优势和劣势的看法.
什么是实现Play与Angular结合的好方法？
我遇到过这种做法：
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails的？无论框架是什么,需求仍然完全相同.
它主张在API(后端端)和前端端(在这种情况下对后端服务器进行AJAX调用)之间进行真正的分离.
因此,我所学到的是：
>在开发阶段,开发人员将使用两个服务器：两个不同端口上的localhost.
>在生产阶段,前端元素将被包含在整个后端(文章将处理一个类型的公共文件夹,旨在提供静态内容：HTML,角度模板(例如),CSS等…优势？=>处理一个唯一的服务器服务器的API展示以及UI的静态资产.
有了这个组织,像Yeoman这样的工具就能够为开发人员带来一些非常棒的便利,例如：livereload功能.
