Tapestry5 与 Play 框架
我知道将一种框架与另一种框架进行比较会产生很多问题。我感觉我还得补充一句。
play框架相对于Tapestry5框架有什么优势？您会推荐哪一款？为什么？
以下是我发现的相似之处。
- 两者都是无状态框架（我知道游戏更加无状态）
- 两者都通过实时类重新加载真正提高了开发人员的工作效率
为什么人们会选择其中一个而不是另一个。我已经使用两者来做“美化的你好世界”类型的应用程序，我觉得两者非常相似。
I know there are many questions here comparing one framework with another. I feel i have to add one more.
What is the advantage of play framework over Tapestry5 framework? Which one would you recommend and why?
Here are the similarities that i have found.
- Both are stateless frameworks (i know play is more stateless)
- Both really boost developer productivity with live class reloading
Why would one choose one over the other. I have used both to do a 'glorified hello world' type of applications and i feel like both are very similar.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
另请注意，Play 似乎不（直接？）与标准应用程序服务器兼容；它不使用 Servlet API，但它有自己的请求和响应定义。
这也相当严厉，在每个请求上重新编译/重新加载 Java 类（抱歉，如果这是 FUD，这是我在 JavaOne 演讲中记得的）。它不是基于组件的，而是基于操作的框架，如 Struts 或 SpringMVC；它使用的模板是对 JSP 的改进，但缺乏 Tapestry 更全周期的方法。 Tapestry 的大部分功能来自于从简单的元素构建复杂的功能。
Tapestry 包含非常复杂的技术，用于处理打包在 JAR 内的资产（图像、样式表、JavaScript 库）。这对用户和开发人员来说都是透明的，只需将 JAR 放在类路径上，它们就会自动加载和配置。
我想玩！有一些好主意，还有一个非常好的名字，但它在与 Tapestry 不同的联盟中发挥作用。它在避免任何服务器端状态方面相当严格......相比之下，Tapestry 使用有限数量的服务器端状态并仔细管理该状态，并且这样做很大程度上是为了拥抱 post-after 语义。
当您在许多不同的页面上具有相同的行为时，您只能进入面向操作的框架。尽管我个人甚至会在单页应用程序上使用 Tapestry，但在与大型团队一起开发大型应用程序时，Tapestry 确实表现出色。
Also note that Play does not appear to be (directly?) compatible with standard application servers; it doesn't use the Servlet API, but it's own definitions of Request and Reponse.
It's rather draconian as well, recompiling/reloading Java classes on each request(sorry if this is FUD, it's what I remember from the JavaOne talk).It is not component based, it's an action based framework, like Struts or SpringMVC; it uses templates that are an improvement on JSPs but lacks Tapestry more full-cycle approach. Much of the power of Tapestry comes from building complex functionality from simple elements.
Tapestry includes very sophisticated technology for dealing with assets (images, stylesheets, JavaScript libraries) that are packaged inside JARs. It's all transparent to the user and to the developer, just drop the JARs on the classpath and they automatically load and configure.
I think Play! has some good ideas, and a very good name, but its playing in a different league than Tapestry. It's rather draconian in avoiding any server-side state ... by contrast, Tapestry uses limited amounts of server-side state and manages that state carefully, and does so largely to embrace redirect-after-post semantics.
There's only so far you can go in an action oriented framework when you have the same behaviors spanning many different pages. Although I, personally, would use Tapestry even on a single-page application, it's true that Tapestry really shines when developing larger-scale apps with larger teams.
我对 Tapestry 没有直接的经验。但我们使用 Play 的项目中的一位同事已经使用过它，他真的厌倦了它。他有很多抱怨，但你可以发现其中大部分都列出了 此处*。
就我个人而言，我认为 Play 与其他框架之间的主要比较点是：
如果您的框架支持所有这些以及 Play，那么您可以更深入地了解细节，例如它是否是无状态/有状态框架等。
*回溯机器版本，因为该帖子已从堆栈溢出中删除。
I have no direct experience with Tapestry. But a colleague in a project where we use Play has worked with it, and he was really fed up with it. He had many complains, but you can find most of them listed here*.
Personally, I think the main comparison points between Play and other frameworks are:
If your framework supports all this as well as Play, then you can go deeper into details, like if it's a stateless/stateful framework, etc.
*Wayback machine version because the post has been deleted from stack overflow.
Play 框架不是基于组件的。没有一个 Java 类支持每个页面。相反，它遵循严格的 MVC 分离，其中应用程序的核心必须直接驻留在模型中。
Play 与 Ruby on Rails 或 Grails 非常相似，但使用的是 Java。
此外，还可以在其自己的内置服务器（基于 JBoss Netty）上部署 Play 应用程序。
选择哪一个主要取决于您如何处理视图层。如果您喜欢纯 HTML、CSS 和 JavaScript，请选择 Play!。如果您更喜欢 Java 组件，请选择 Tapestry。
The Play framework is not component based. There is not a Java class backing every page. Instead, it follows a strict MVC separation, where the meat of the application must reside squarely in the model.
Play is meant to be very similar to Ruby on Rails or Grails, but in Java.
Also, it is possible to deploy a Play application on its own built-in server (based on JBoss Netty).
Which one you choose mainly depends on how you approach the view layer. If you prefer plain HTML, CSS and JavaScript, go with Play!. If you prefer Java components, go with Tapestry.
我根本不会玩，我只看过一些5分钟的介绍，但不喜欢它，但我对Tapestry 5有一些经验。
优点是什么：
顺便说一句，动作书中的 Tapestry 5 刚刚在 MEAP 上提供
。再次请注意，我对游戏一无所知，只是试图解决您提到的问题。如果您想了解 Tapestry 的更多优点（不是过度使用，而是框架的整体优势，请给我留言。我很乐意写更多内容（特别是在我正在说服客户从 Spring 切换到 T5 的过程中，并且欢迎在演讲之前进行任何练习；））
问候
米哈乌
I don't know play at all, I have seen only some 5 min introductions, but didn't like it, but I have some experience with Tapestry 5.
What are advantages:
BTW tapestry 5 in action book just became available on MEAP
Once again, please note that I have no idea about play and was only trying to address points you mentioned. If you want more advantages of Tapestry (not over play, but overall strong sides of framework, please message me. I'll be happy to write more (especially as I'm in process of convincing client to switch from Spring to T5, and any practice before that talk is welcome ;) )
Regards
Michał
玩的好处！框架与 Tapestry5 的比较是：
Tapestry5 也有第 3 方模块 - 但它们不会节省您的时间，它们会消耗时间。其中大多数都没有维护，您总是需要分叉、理解和修改所有第 3 方代码，以便它可以与最新的 Tapestry 版本一起使用。最后，自己编写所有内容会更容易。一般来说，Tapestry5 更昂贵，因为您需要计算代码维护。在每次 Tapestry 升级中，您都需要更改代码，因为方法已被弃用 - 不仅在您自己的代码中，而且在您集成的来自第三方的所有其他模块中。这是一个很大的时间杀手，而且要花很多钱。
与《玩！》相比您可以在其中获取诸如 Facebook/oAuth 身份验证之类的东西，它就可以正常工作 - 而且在框架的下一次更新中，这是一个巨大的成本效益。
一般来说，我一直认为 Java Web 应用程序的开发、维护和托管成本最高。然而，通过 Play!，计算变得越来越好 - 尽管该方法有时不太“智能”。但如果上市时间和开发成本很重要，那就选择 Play！或其他一些技术，例如 RubyonRails 或 PHP。然而，RubyonRails 开发人员的成本与 Java 开发人员一样昂贵。
The benefits of the Play! framework vs. Tapestry5 are:
There are also 3rd party modules for Tapestry5 - but they will not save you time, they will consume time. Most of them are not maintained and you always need to fork, understand and modify all 3rd party code so it will work with the latest Tapestry versions. In the end, it is easier to write everything yourself. In general Tapestry5 is more expensive as you need to calculate code maintenance. On every Tapestry upgrade, you need to change your code as methods are deprecated - not only in your own code but all other modules from 3rd parties you have integrated. This is a big time killer and costs a lot of money.
Compared to Play! where you can just grab something like Facebook/oAuth authentication and it just works - also in the next updates of the framework, this is a huge cost benefit.
In general I always though Java webapps are most expensive to develop, maintain and host. However with Play!, the calculation is getting better - although the approach is sometimes less "intelligent". But if time-to-market and development costs count go for Play! or some other technology such as RubyonRails or PHP. However RubyonRails developers are as expensive as Java folks.
我还想说，即使对于 Play 和 Tapestry 用户来说，Tapestry 比 Play 更传统，也更容易满足标准，这一点很明显。我不认为这是好事还是坏事。再说一次，去人迹罕至的地方通常并不是坏事。 Play有一个非常好的内置自制东西。因此，您不需要那么多额外的模块或将 Play 插入其他库。
两者都有出色的内置功能：显然令人难以置信的实时类重新加载、注入……有时一个比另一个有更好的支持（例如，REST for Play）。它们都确实提高了生产力。 但是 Tapestry 比 Play 更接近标准。
您不需要在 Play 中包含 REST 支持，也不需要使用 Servlet 引擎或插入任何构建系统。这是一价全包的优惠:)。但当您需要在专业环境中满足标准标准时，这就相当困难了。
我最近不得不做出两次选择。
所以，从我的角度来看，这是这两个令人难以置信的框架之间的主要区别之一。
Matt Raible（即使有争议；））说你不应该从可以的框架中选择框架做，但考虑到他们不能做什么！ 这显然是这里的主要争论！他们都可以做出伟大的作品，但以两种略有不同的方式:)
I would also say, even it's obvious for both Play and Tapestry users, that Tapestry is more conventional than Play, and meet more easily standards. I would not argue that's a good or a bad thing.Once again, it's not often a bad things to go somewhere off the beaten track. Play have a really good built-in home made stuff. So you don't need so much extra modules or plug Play to other librairies.
Both have great built-in features : live class reloading that is clearly incredible, injection, ... Sometimes one have better support than the other (REST for Play, for instance). They both really improve productivity. But Tapestry is quite more closer from standard than Play.
You don't need to include REST support in Play, neither to use a Servlet engine or plug any build system. It's an ALL-INCLUSIVE offer :). But when you need to meet standards criterias in a professional context, it's quite more difficult.
I recently had to make the choice, two times.
So, this is, from my point of view one of the main differences between those two incredibles frameworks.
Matt Raible (even if controversed ;)) said you should not choose framework from what the can do, but regarding on what they can't ! Its clearly the main debate here ! The can both do great works, but in two slightly different ways :)