任何与“玩”Java Web开发框架的经验？
我刚刚发现了以下新的Java Web框架：Play
http://www.playframework.org/
http://www.playframework.org/documentation/1.0/home
有这样一个惊人的function列表，我感到非常惊讶，我没有听说过它…
听起来像java web开发承诺的土地…
有人试过吗？ 任何真正的经验呢？ 你认为值得研究吗？
我同意Jason的观点，Play可能会比Grails更好。 在我的带子下有四个Grails项目（之前有两个Tapestry项目和一个Wicket项目），接下来我认真的看着Play。
我认为对于Grails很酷的事情之一就是“Groovy的一切”。 也就是说，您使用Groovy来编写一切（除了HTML和CSS） – 域，控制器，服务，页面模板（GSP），标记库，Hibernate API（GORM），unit testing（GUnit）和构build脚本GANT）。 你甚至可以在Groovy中编写shell脚本。 因此，能够使用单一语言对应用程序的各个方面进行编码似乎是一个早已过时的简化 – 回想起用C ++或Delphi之类的单一语言编写桌面应用程序的时代。 但是，我了解到，一个尺寸并不适合这里。
首先，对Groovy的IDE支持不是很好。 IntelliJ做的最好，但是Groovy是dynamic的，只能走得这么远。 重构工具没有（不能）抓住一切，所以你不能相信他们100％。 这意味着你必须特别警惕unit testing。 在这里再一次，因为Grails依赖于运行时发生的dynamic“魔法”，Grails中的unit testing必须依赖广泛的模拟层来模拟它，而模拟层是古怪的。 第三个问题是，你写的所谓的Groovy代码实际上是域特定语言（DSL）代码。 （简而言之，DSL是短期的Groovy，利用了Groovy中的许多优势，而且很多语法都是可选的。）Grails使用不同的DSL来进行各种configuration，URL映射等，这是不一致的。 例如，如何指定log4j设置，看起来不像指定数据源的方式，也不像Groovy所基于的纯Java。 所以，“一切的Groovy”的承诺无论如何分崩离析。
既然如此，我看看Play团队来自哪里。
-
回到正常的Java领域，控制器，服务和JUnits是有道理的。 强键入意味着IDE可以可靠地帮助进行inteli-sense，代码导航，重构等等（因此，如果您对Eclipse感到满意，则无需为IntelliJ支付费用）。必须编写更详细的代码才能获得强大的工具支持似乎对我来说是一个很好的交易。 我们拭目以待。
-
我喜欢我仍然可以在页面模板中使用Groovy。 尽pipe如此，恐怕我最终可能会在模板中放置更多的代码。
-
我没有使用JPA的经验，但是看起来GORM对我来说非常接近，所以这很酷。
-
Grails中的Spring IOC支持是完全透明的，而Play的支持似乎是最小的; 然而，我认为国际奥委会被滥用，我非常愿意在罕见的情况下手工编写一个Spring XML映射。 （我的一个悬而未决的问题是，我假设JPA有交易支持，这就是为什么Play不需要像Grails那样的Spring，不是吗？）
-
我从来没有成为Python的粉丝，所以当我读到Play使用Python构build脚本时， 但是我同意Grails的GANT脚本运行速度很慢。 另外，我发现，虽然GANT是XML ANT的一个巨大改进，但围绕ANT概念仍然很难。 Grails GANT脚本非常复杂。 所以，我会以开放的态度去做。
-
Play“应用程序模块”模型听起来就像Grails的“插件”模型，所以很酷。
-
迄今为止我读过的Play文档给我留下了深刻的印象。 我遇到了很多问题，但其中有一半的问题已经被解决了。
稍后我会再深入报道。
我已经尝试了Play，我留下了深刻的印象：它提供了一个比大多数框架简单得多的有用的开发模式。 更重要的是，运行时的'开发模式'直接parsing.java文件的能力是值得的：只需在浏览器中重新加载网页而不运行构build脚本或等待重新部署就值得大量的开发速度。 浏览器中显示的错误信息也非常好。
另一件令我印象深刻的事情是整体美学：教程应用程序实际上看起来很不错（代码和网页devise），但是这延伸到了整个框架，API以及文档。
在一个同事的刺激之后，我看了一下，跟着教程，然后迷上了。 在您的浏览器中即时获得反馈意味着您不必使用IDE。 我喜欢Eclipse，但让我们面对现实吧：在添加了一些额外function之后，它不如简单的文本编辑器那样稳定。 在使用TextMate的Mac上，您甚至可以在浏览器中单击错误消息，并在该行上popupTextMate。
Play中的testing也很好地完成，只需按一下button即可运行unit testing，functiontesting和基于Selenium的testing。
玩是令人兴奋的，因为它仍然很小，并不复杂。 它只用ant来build立，并在25秒内完成。 对美丽文档的贡献是编辑.textile文件并在任何游戏应用程序中重新加载文档的问题。
这就是我在寻求翻译教程以使用Scala的过程中最终完成的任务，在需要的时候join到Scala支持中，尽可能地让它变得更好。
我喜欢它，我将它用于小型项目，到目前为止，它看起来是完美的工作。 然而，我非常想念的一件事是被遗漏的：Service / DAO / Model层分离！ 文档中明确指出，Play的目标之一是避免“贫血数据模型”： http ://www.playframework.org/documentation/1.0.1/model
但是根据我的经验，当应用程序需要重构时，传统的Service / DAO / Model图层分离节省了大量的开发时间！ 使用Play时，您会遇到依赖于Play特定事务pipe理和特性的静态方法。
然而，许多人赞成：开发速度，代码清洁，并最终…乐趣！
我用过Grails，Tapestry 4/5和直接的Java / JSP / Spring / Hibernate。
我认为这是很长一段时间以来第一次朝着正确的方向发展。 Grails是一个非常好的第一步，但玩！ 看起来像是真的可以有腿的东西。 Scala支持即将到来1.1。 如果有机会，我可以写我的控制器/ Clojure的域名，我被出售;）
由于一年之后，18个小版本发布后没有可见的bug，我们使用Play！ 1.2.4在一个学校生产“缺席”内联网申请（演员：> 100名教师，> 700名学生，行政队）。 客户端已经使用Adobe的FLEX 4.6编写（非常漂亮的视图）。 数据以AMF3格式（Cinnamon模块）发送和接收。 我们使用基于JPA EclipseLink和MySql的数据库自己的简单dao层。 应用程序存储在Linux虚拟服务器上。 我是Play的粉丝开发者，因为它的简单性和非常高效的方法。
我喜欢Play的外观，但还没有尝试过。 通过文档扫描，突出的一件事情是大量使用静态方法。 从unit testing的angular度来看，这总是使事情变得更加困难（我正在考虑模拟），这与典型Java开发中的面向对象的处理方法是背道而驰的。 也许这是重点，但这只是让我不那么热血沸腾…
我目前正在使用大规模数据处理的游戏框架来构buildWeb应用程序。 我必须说，游戏提供的速度是显着的，而且比RoR能提供的要多。 另外，play是一个基于java的框架，因此multithreading可以轻松完成。 接下来是你使用基于Java的模块（如Japid和Netty）以及游戏时获得的绝对性能。就像性能无穷无尽的调整一样。 一定要试试我的意见。
我在一个小项目中使用Play，似乎正是他们所说的。 但是我认为在框架中默认存在一个特性：能够使用多个数据源（例如，使用多个数据库模式）。 这是我迄今为止发现的唯一缺失的function。
问候，Uilian。
