GWT 与 Apache Wicket 对比

发布于 2024-10-10 12:20:43 字数 198 浏览 4 评论 0原文

GWT 和 Wicket 都是有状态的、基于 Java 对象的。 GWT 完全基于客户端,具有 JavaScript 优化、CSS 优化等功能,而且我对 Apache Wicket 还很陌生。

我对 Wicket 的了解越多,就越感觉它与 GWT 相似。

所以我想问题是 - GWT 和 Wicket 之间有什么区别?或者我正在将苹果与橙子进行比较?

Both GWT and Wicket are stateful, java object oriented based. GWT is completely client based with features like javascript optimization, CSS optimization, and I'm pretty new to Apache Wicket.

The more I read about Wicket the more similar it feels to GWT.

So I guess the question is - What are the differences between GWT and Wicket? Or am I comparing apples to oranges?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

弥枳 2024-10-17 12:20:43

我多年来一直在一个大型项目中使用 GWT(1.x 和 2.x)和 Wicket(1.4、1.5),这两个框架都有其优点和缺点。它们都很酷而且很好,如果它们用于它们的设计目的。但您可以通过轻松地将它们混合在一起来充分利用两者。

  • Wicket 对于 CRUD 网站来说确实非常好而且功能强大,页面设计 (HTML) 和 Java 代码之间有很好的分离。只要您不需要强大的客户端功能,它就可以很好地完成工作,但代价是代码有点冗长:但这就是强类型化所付出的代价:没有“魔法” ”; 重构组件化很有魅力。对于大型项目,它可以轻松解耦,并且经过精心设计,可以与大型团队合作:人们可以专注于提供一组很好的核心组件,其他在表示层上,等等...唯一的缺点是对于客户端的复杂行为,您仍然需要掌握 Javascript,并且您自己混合 Wicket 和 Javascript 很容易变得相当复杂。< /p>

  • 当您确实需要客户端(类似 GMail 的应用程序)上具有丰富的行为功能时,GWT 非常有用。 GWT 的主要问题是它在纸面上看起来太漂亮了(“java 中的一切”范例),但它并没有兑现它的承诺。它不能很好地扩展:GWT 适合提供少量功能的小型模块,而不适合大型应用程序。代码/编译/调试周期相当长,当模块大小变得太大时,就会成为负担。此外,它不能很好地支持大型团队在同一模块上同时工作。

总而言之,我建议人们必须选择:

  • 确实需要时谨慎使用 GWT,保持模块大小,并且永远不要尝试完全用它构建整个大型应用程序;
  • 其余的使用检门(检门真的很棒!)。
  • 要将两者混合在一起,请使用 Wicket 强大的组件功能以“wicket 方式”模块化 GWT 代码(GWT 模块成为一种特殊类型的 Wicket 组件),并且保持 GWT 小

I have been using both GWT (1.x and 2.x) and Wicket (1.4, 1.5) on a large project for several years now, and both frameworks have their advantages and drawbacks. Both of them are cool and nice, if they are used for what they have been designed for. But you can take the best of both by mixing them together easily.

  • Wicket is really nice and powerful for CRUD websites, with a good separation between the page design (HTML) and the Java code. As long as you do not need powerful client capabilities it's doing it's job very nicely, at the prize of being a bit code-verbose: but that's the prize to pay to be strongly typed: there's no "magic"; refactoring and componentization works like a charm. For large projects it can be easily decoupled and is well designed to work with large teams: people can focus on providing a nice set of core components, other on the presentation layer, etc... The only drawback is for complex behavior on client side, you still need to master Javascript and it can easily become rather complex to mix Wicket and Javascript yourself.

  • GWT is nice when you really need rich behavior capabilities on your client (GMail-like application). The main problem with GWT is that it look too nice on paper (the "everything in java" paradigm), but it does not fulfill it's promises. It does not scale well: GWT is nice for small modules providing a small set of functionalities, not for large applications. Code/compile/debug cycle is rather long, and when module size grows too large it becomes a burden. Also it does not support well large teams working concurrently on the same module.

To summarize, I would suggest people having to choose:

  • Use GWT sparingly when it's really needed, keeping module size small, and never try to build a whole big application entirely with it;
  • Use wicket for the rest (Wicket really rocks!).
  • To mix both together, use the powerful component capabilities of Wicket to modularize GWT code in a "wicket way" (GWT modules becoming a special kind of Wicket components), and again, keep GWT small.
断肠人 2024-10-17 12:20:43

这几乎是从苹果到橙子。

wiki 条目总结了一些相似点和不同点,以及一起使用它们的策略的开始,我认为这是一个有趣的想法。

Wicket 主要是一种服务器端技术,具有一些内置的 Ajax 支持和用于连接更多 Ajax 的挂钩。它不像 GWT 那样将 Java 转换为 JavaScript。它在服务器端维护状态,而 GWT 在客户端维护状态。

两者都是基于组件的,对我来说有一些 Swing 开发的感觉(尽管 Wicket 似乎对至少一位其他受访者来说不像 Swing)。

It is pretty much apples to oranges.

This wiki entry summarizes some of the similarities and differences, and the start of a strategy for using them together, which I think is an interesting idea.

Wicket is primarily a server-side technology with some built-in Ajax support and hooks for wiring in more Ajax. It does not translate Java to JavaScript like GWT. It maintains state server-side where GWT maintains state on the client.

Both are component-based and to me have something of the feeling of Swing development (though Wicket doesn't seem to feel like Swing to at least one other respondent).

半山落雨半山空 2024-10-17 12:20:43

该线程活跃已过去 6 年,而 GWT 几乎停滞不前。
Wicket 似乎得到了更加积极的开发和支持。
有人对 Wicket 或其他选项有新的看法吗?

It's been 6 years since this thread was active and GWT has mostly stagnated.
Wicket seems to be much more actively developed and supported.
Anyone have newer opinions about Wicket or other options?

前事休说 2024-10-17 12:20:43

Wicket 是基于服务器的框架。它比 GWT 更类似于 JSf。 GWT 在概念上与 Swing 类似,我是前 Swing 开发人员,从 swing 迁移到 gwt 非常容易。但我不能对 Wicket 或 JSF 说同样的话。

Wicket is server based framework.. It is much more similar to JSf than GWT. GWT is conceptually similar to Swing, I am ex-swing developer, it is very easy to migrate from swing to gwt. But I cant say same things for Wicket or JSF..

混浊又暗下来 2024-10-17 12:20:43

Wicket 是服务器框架。它允许创建您需要的 html。项目中的角色是可能分离的。 (网页设计->html/css->java)。

如果您考虑在您的项目中使用 GWT,则可能不需要网页设计器。
GWT 生成 JavaScript。大多数逻辑可以在浏览器端执行。 GWT 更适合可扩展的应用程序。

Wicket is server framework. It allow to create html which you needed. It is possible separation of roles in project. (Web design->html/css->java).

If you consider to use GWT for you project, web designer probably not needed.
GWT generate javascript. Most logic can be executed on browser side. GWT better for scalable application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文