Apache Wicket ( http://wicket.apache.org/ ) 和 Apache Tapestry ( https://tapestry.apache.org/ ）都是面向组件的 Web 框架 - 与基于操作的框架，例如由 Apache 基金会开发的 Stripes。 两者都允许您从 Java 组件构建应用程序。 他们看起来都和我很相似。
这两个框架有什么区别？ 有人两者都有经验吗？ 具体来说：
- 它们的性能如何，状态处理可以定制多少，它们可以无状态使用吗？
- 他们的组件模型有什么区别？
- 您会为哪些应用选择什么？
- 它们如何与 Guice、Spring、JSR 299 集成？
编辑：我已经阅读了两者的文档并且使用了两者。 通过阅读文档无法充分回答这些问题，但可以通过使用这些文档一段时间的经验来回答，例如如何在无状态模式下使用 Wicket 来实现高性能站点。 谢谢。
Apache Wicket ( http://wicket.apache.org/ ) and Apache Tapestry ( https://tapestry.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.
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?
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.
发布评论
评论（8）
我看到的一些相关差异：
结构，您可以在其中使用
条件和循环来实现
动态行为。 检票口是
完全动态； 你可以加载
动态组件，替换它们
在运行时等的后果
这是 Tapestry 更容易做到的
优化，Wicket 更
使用灵活。
大致相同效率
执行，但 Wicket 依赖于
服务器端存储（默认情况下
会话中的当前页面和过去的页面
“二级缓存”中的页面
文件中默认是临时文件
系统）。 如果这让你烦恼，想一想
关于有多少并发会话
您期望在高峰时间有
计算一下，每个会话约 100kb
（这可能偏高）。
这意味着你可以大致运行
支持 20k 并发会话
2GB。 说 15k 因为你需要它
对其他事物的记忆也是如此。 的
当然，存储的缺点
状态是它只会运作良好
具有会话亲和力，所以这是
使用 Wicket 时的限制。 这
框架为你提供了一种手段
实现无状态页面，但是如果
你正在开发完全无状态的
您可能会考虑的应用程序
不同的框架。
我已经读过几次，人们认为 Wicket 通过继承来工作。 我想强调的是，你有选择的权利。 组件具有层次结构，但 Wicket 还支持通过 IBehavior 等构造进行组合（例如，Wicket 的 Ajax 支持是在其之上构建的）。 最重要的是，您可以将转换器和验证器之类的东西添加到全局组件中，甚至可以使用 Wicket 提供的一些阶段侦听器作为横切关注点。
Some relevant differences as I see them:
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.
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.
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.
在学习 Tapestry 5 之后修订。
Wicket 的目标是尝试使Web 开发类似于桌面 GUI。 他们以消耗内存（HTTPSession）为代价成功地做到了这一点。
Tapestry 5 的目标是打造非常优化（针对 CPU 和内存）面向组件的 Web 框架。
对我来说真正的大陷阱是响应“Wicket 支持无状态组件！” 论点“Wicket 内存匮乏”。 虽然 Wicket 确实支持无状态组件，但它们并不是“Wicket 开发的重点”。 例如，StatelessForm 中的错误很长时间没有得到修复 - 请参阅 StatelessForm - 验证失败后参数出现问题。
不幸的是 Tapestry 5 教程 并没有强调像 't:loop source 这样的 Tapestry 代码示例="1..10"...' 可能是一个不好的做法。 因此，如果您的团队不是很小，应该花一些精力来编写 Tapestry 使用约定/良好实践。
我的建议：
REVISED after studying Tapestry 5.
Wicket's goal is an attempt to make web development similar to desktop GUI one. They managed to do it really well at the expense of memory usage ( HTTPSession ).
Tapestry 5's goal is to make very optimized (for CPU and memory) component oriented web framework.
The really big pitfall for me was 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.
Unfortunately Tapestry 5 tutorial does 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.
My recommendations:
以下是来自 IBM Developer Works 的相当全面的比较。
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
Here's a pretty thorough comparison from IBM's Developer Works.
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
我认为 Wicket 是一个使用起来更简单的框架。
此外，Wicket 确实允许通过 IDE 的热代码替换系统重新加载类。 这就是 Wicket 运行当前正在运行的应用程序类的修改版本所需的全部内容。 通常的限制适用于热代码替换，例如必须在调试模式（Eclipse）下运行并且无法更改类的结构方面（即类名、更改方法签名等...）。
I think Wicket is a simpler framework to use.
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 是非常好的Web 框架。 据我所知最好的。 我从 1.3 版本开始就使用它，并且总是能得到我想要的。
Wicket 与 Spring 具有出色的集成 - 只需在代码中使用 @SpringBean 注释即可将任何 spring bean 注入到您的类中。
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.
尝试 http://incubator.apache.org/click/ 。
这是一个令人惊叹的 Java Web 框架。
有些人称之为“检票正确”;-)
Try http://incubator.apache.org/click/ .
It is amazing java web framework.
Some people call it “Wicket made right” ;-)
我不喜欢 Tapestry 编程模型，并且我知道许多开发人员因为开发中的太多变化和不兼容性而离开 Tapestry。 请参阅：http://ptrthomas.wordpress .com/2009/09/14/perfbench-update-tapestry-5-and-grails/
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/
正如我在 4.1 正式稳定版本发布时所说的那样：
在承诺使用 Tapestry 之前，您应该仔细研究一下 Tapestry 的开发历史。 Tapestry 做了很多不兼容的升级，没有继续支持旧版本。 在合理的时间内不再处理 4.1 的补丁。 在我看来，这对于官方稳定版本来说是不可接受的。
承诺使用 Tapestry 5 意味着：
您应该成为一名提交者；
你需要跟上所有新的发展，尽快放弃旧版本；
自己维护稳定版本。
As I said when 4.1 was the official stable release:
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.
Committing to use Tapestry 5 means:
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.