java Apache Tapestry 和 Apache Wicket 的区别
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/657352/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Difference between Apache Tapestry and Apache Wicket
提问by KingOfCoders
Apache Wicket ( http://wicket.apache.org/) and Apache Tapestry ( http://wicket.apache.org/) are both component oriented web frameworks - contrary to action based frameworks like Stripes - by the Apache Foundation. Both allow you to build your application from components in Java. They both look very similar to me.
Apache Wicket ( http://wicket.apache.org/) 和 Apache Tapestry ( http://wicket.apache.org/) 都是面向组件的 Web 框架- 与 Stripes 等基于动作的框架相反 - 由 Apache 基金会开发。两者都允许您从 Java 组件构建应用程序。他们看起来都和我很相似。
What are the differences between those two frameworks? Has someone experience in both? Specifically:
这两个框架有什么区别?有人在这两个方面都有经验吗?具体来说:
- How is their performance, how much can state handling be customized, can they be used stateless?
- What is the difference in their component model?
- What would you choose for which applications?
- How do they integrate with Guice, Spring, JSR 299?
- 它们的性能如何,状态处理可以定制多少,它们可以无状态使用吗?
- 他们的组件模型有什么区别?
- 你会为哪些应用选择什么?
- 它们如何与 Guice、Spring、JSR 299 集成?
Edit: I have read the documentation for both and I have used both. The questions cannot be answered sufficently from reading the documentation, but from the experience from using these for some time, e.g. how to use Wicket in a stateless mode for high performance sites. Thanks.
编辑:我已经阅读了两者的文档并且我已经使用了两者。这些问题不能从阅读文档中得到充分回答,但可以从使用这些文档一段时间的经验中得到充分回答,例如如何在高性能站点的无状态模式下使用 Wicket。谢谢。
采纳答案by Eelco
Some relevant differences as I see them:
我看到的一些相关差异:
- Tapestry uses a semi-static page structure, where you can work with conditionals and loops to achieve dynamic behavior. Wicket is completely dynamic; you can load components dynamically, replace them at runtime, etc. The consequences of this are that Tapestry is easier to optimize, and that Wicket is more flexible in it's use.
- Both frameworks are roughly equally efficient in execution, but Wicket relies on server side storage (by default the current page in session, and past pages in a 'second level cache' which is default a temp file in the file system). If that bothers you, think about how many concurrent sessions you expect to have at peak times and calculate with say ~100kb per session (which is probably on the high side). That means that you can run roughly support 20k concurrent sessions for 2GB. Say 15k because you need that memory for other things as well. Of course, a disadvantage of storing state is that it'll only work well with session affinity, so that's a limitation when using Wicket. The framework provides you with a means to implement stateless pages, but if you're developing fully stateless applications you might consider a different framework.
- Wicket's goal is to support static typing to the fullest extent, whereas Tapestry is more about saving lines of code. So with Tapestry your code base is likely smaller, which is good for maintenance, and with Wicket, you much is statically typed, which makes it easier to navigate with an IDE and check with a compiler, which also is good for maintenance. Something to say for both imho.
- Tapestry 使用半静态页面结构,您可以在其中使用条件和循环来实现动态行为。Wicket 是完全动态的;您可以动态加载组件,在运行时替换它们等。这样做的结果是 Tapestry 更容易优化,Wicket 在使用上更灵活。
- 两种框架的执行效率大致相同,但 Wicket 依赖于服务器端存储(默认情况下会话中的当前页面,以及“二级缓存”中的过去页面,后者默认为文件系统中的临时文件)。如果这让您感到困扰,请考虑您希望在高峰时间拥有多少并发会话,并计算每个会话约 100kb(这可能偏高)。这意味着您可以为 2GB 运行大约支持 20k 个并发会话。说 15k,因为您也需要该内存来处理其他事情。当然,存储状态的一个缺点是它只适用于会话关联,所以这是使用 Wicket 时的一个限制。该框架为您提供了一种实现无状态页面的方法,但是如果您
- Wicket 的目标是最大限度地支持静态类型,而 Tapestry 则更多地是为了节省代码行。因此,使用 Tapestry 时,您的代码库可能更小,这有利于维护,而使用 Wicket,您的大部分代码都是静态类型的,这使得使用 IDE 导航和使用编译器检查更容易,这也有利于维护。恕我直言,有话要说。
I have read a few times by now that people think Wicket works through inheritance a lot. I would like to stress that you have a choice. There is a hierarchy of components, but Wicket also supports composition though constructs like IBehavior (on top of which e.g. Wicket's Ajax support is built). On top of that you have things like converters and validators, which you add to components, globally, or even as a cross cutting concern using some of the phase listeners Wicket provides.
我已经读过几次,人们认为 Wicket 是通过继承来工作的。我想强调的是,你有一个选择。有一个组件层次结构,但 Wicket 也通过像 IBehavior 这样的构造来支持组合(例如,在其上构建了 Wicket 的 Ajax 支持)。最重要的是,您有转换器和验证器之类的东西,您可以将它们添加到组件中,全局添加,甚至使用 Wicket 提供的一些相位侦听器作为交叉关注点。
回答by Sergey
REVISEDafter studying Tapestry 5.
学习 Tapestry 5 后修订。
Wicket's goalis an attempt to make web development similar to desktop GUIone. They managed to do it really well at the expense of memory usage ( HTTPSession ).
Wicket 的目标是尝试使Web 开发类似于桌面 GUI。他们以牺牲内存使用( HTTPSession )为代价,成功地做到了这一点。
Tapestry 5's goalis to make very optimized (for CPU and memory)component oriented web framework.
Tapestry 5 的目标是制作非常优化(针对 CPU 和内存)的面向组件的 Web 框架。
The really big pitfall for mewas responses "Wicket supports stateless component!" to the arguments "Wicket is memory hungry". While Wicket indeed supports stateless components they are not "a focus of Wicket development". For example a bug in StatelessForm was not fixed for a very long time - see StatelessForm - problem with parameters after validation fails.
对我来说真正的大陷阱是回应“Wicket 支持无状态组件!” 论点“Wicket 是内存饥渴”。虽然 Wicket 确实支持无状态组件,但它们并不是“Wicket 开发的重点”。例如,StatelessForm 中的一个错误在很长一段时间内都没有得到修复——参见StatelessForm——验证失败后参数的问题。
- IMHO using Wicket is a bit eaiser until you are going to optimize/ fine-tune web application parameters
- IMHO Wicket is harder to study if you have programmed web applications and want to think in terms of request processing
- Tapestry 5 automatically reloads component classesas soon as you change them. Both frameworks reload component markup.
- Wicket forces markup/ code separation, Tapestry 5 just give you this ability. You can also use less verbose syntax in Tapestry 5. As always this freedom requires more cautions to be taken.
- Wicket's core is easier to debug: user components are based on inheritance while Tapestry 5 user components are based on annotations. From the other side that could make transitions to the future versions easier for Tapestry then for Wicket.
- 恕我直言,在您要优化/微调 Web 应用程序参数之前,使用 Wicket 会更容易一些
- 恕我直言,如果您编写了 Web 应用程序并想在请求处理方面进行思考,那么 Wicket 就更难研究
- 一旦您更改组件类,Tapestry 5 就会自动重新加载它们。两个框架都重新加载组件标记。
- Wicket 强制标记/代码分离,Tapestry 5 只是给你这个能力。您还可以在 Tapestry 5 中使用不那么冗长的语法。与往常一样,这种自由需要更加谨慎。
- Wicket 的核心更易于调试:用户组件基于继承,而 Tapestry 5 用户组件基于注释。另一方面,这可以使 Tapestry 和 Wicket 更容易过渡到未来版本。
Unfortunately Tapestry 5 tutorialdoes not stress that Tapestry code example like 't:loop source="1..10"...' can be a bad practice. So some effort should be put into writing Tapestry usage conventions/ good practices if your team is not very small.
不幸的是,Tapestry 5 教程没有强调像 't:loop source="1..10"...' 这样的 Tapestry 代码示例可能是一种不好的做法。因此,如果您的团队不是很小,应该付出一些努力来编写 Tapestry 使用约定/良好实践。
My recommendations:
我的建议:
- Use Wicket when your pages structure is very dynamic and you can afford spending 10-200 Kbs of HttpSession memory per user (these are rough numbers).
- Use Tapestry 5 in cases when you need more efficient usage of resources
- 当您的页面结构非常动态并且您可以负担每个用户花费 10-200 Kbs 的 HttpSession 内存(这些是粗略的数字)时,请使用 Wicket。
- 在需要更有效地使用资源的情况下使用 Tapestry 5
回答by Scott Swank
Here's a pretty thorough comparison from IBM's Developer Works.
这是来自 IBM 的 Developer Works 的非常彻底的比较。
http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
Update: link is dead, but you can find the page on http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
更新:链接已失效,但您可以在http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html上找到该页面?ca=drs
回答by Antony Stubbs
I think Wicket is a simpler framework to use.
我认为 Wicket 是一个更易于使用的框架。
Also, Wicket does allow for class reloading via your IDE's hot-code replace system. This is all that is required for Wicket to run off modified versions of a currently running application's classes. The usual restrictions apply for hot-code replace, such as having to run in Debug mode (Eclipse) and not being able to change structural aspects of a class (i.e. class name, changing method signatures etc...).
此外,Wicket 确实允许通过 IDE 的热代码替换系统重新加载类。这就是 Wicket 运行当前正在运行的应用程序类的修改版本所需的全部内容。通常的限制适用于热代码替换,例如必须在调试模式 (Eclipse) 下运行并且不能更改类的结构方面(即类名、更改方法签名等...)。
回答by deamon
I don't like the Tapestry programming model and I know of many developers leaving Tapestry because of too much changes and incompatibilities in development. See: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
我不喜欢 Tapestry 编程模型,我知道很多开发人员因为开发中的太多变化和不兼容而离开了 Tapestry。请参阅:http: //ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
回答by Stephan Eggermont
As I said when 4.1 was the official stable release:
正如我在 4.1 是官方稳定版本时所说的:
You should take a very good look at the development history of Tapestry before committing to use it. Tapestry has done a lot of non-compatible upgrades, with no continuation of support of older versions. Patches to 4.1 are not processed anymore within a reasonable timeframe. That is in my point of view not acceptable for the official stable version.
在承诺使用 Tapestry 之前,您应该好好看看它的发展历史。Tapestry 做了很多不兼容的升级,没有继续支持旧版本。在合理的时间范围内不再处理 4.1 的补丁。这在我看来对于官方稳定版本是不可接受的。
Committing to use Tapestry 5 means:
承诺使用 Tapestry 5 意味着:
you should become a committer; you need to keep up with all new development, abandon old versions as fast as possible; maintain stable versions yourself.
你应该成为一名提交者;你需要跟上所有新的发展,尽快放弃旧版本;自己维护稳定版本。
回答by Andrej Fink
Try http://incubator.apache.org/click/. It is amazing java web framework. Some people call it “Wicket made right” ;-)
试试http://incubator.apache.org/click/。这是一个了不起的 java web 框架。有些人称之为“Wicket made right”;-)
回答by Alexey Sviridov
Wicket is very good web framework. Best from all what i'm know. I'm use it since version 1.3 and always get what i'm want. Wicket has excellent integration with Spring - just use @SpringBean annotation in you code to inject any spring bean to your classes.
Wicket 是一个非常好的网络框架。据我所知,最好的。我从 1.3 版开始使用它,并且总是得到我想要的。Wicket 与 Spring 具有出色的集成 - 只需在代码中使用 @SpringBean 注释即可将任何 spring bean 注入到您的类中。

