Apache Wicket有哪些缺点？

Question

我已经阅读了很多关于Apache Wicket的好消息,但很难找到坏事.由于没有框架始终是解决每个问题的正确解决方案,Wicket的缺点是什么以及您不使用哪种类型的项目？

也许不是一个流行的问题,但我认为这是一个重要的问题.

Answer 1

Wicket需要一些非常可靠的编码实践.例如,如果您在组件中存储IModel,但不将其用作组件的模型,则它不会自动分离并且可能会破坏会话大小.这种管理不是大多数Java用户习惯的.

Wicket活跃且经常更新.这很好,但每次我更新到新版本时,我都意识到我需要进行大量的重构才能转向更好的编码实践(1.4引入的泛型,1.4.x引入了onConfigure(),1.5有一些不同的资源策略).同样,所有这些都是很好的更新,并推动你更好的代码,但我羡慕人们现在来到Wicket,而不是两年前:)

结合上述两点,我觉得Wicket在你超越基本功能集后会假设一些真正的编程技巧.如果你是一个优秀的开发人员,你会喜欢Wicket可以为你做的事情(而且代码在JavaDoc中有很好的记录).如果你是初学者,当你变得更深时,你可能会感到沮丧.

此外,虽然它在Google App Engine上"有效",但我发现有几个问题阻止它在该环境中舒适地工作.这是一个不同的讨论.

我的免责声明是我没有使用任何其他东西,所以也许其他框架更糟糕.

Answer 2

在现实世界中,Wicket的开发速度非常慢.如果您没有像装配线上的工厂工人那样使用预先封装的组件,那么生产率会停止,直到您可以制作新的Panel.代码复杂性增加,并且很难读取代码,因为您实际上是要加倍编写的代码行.你一直在寻找如何在互联网和书籍上做琐碎的事情.例如,一个简单的重置按钮是一行HTML,但在Wicket中需要谷歌搜索如何执行此操作.它使简单的事情变得艰难而艰难.

我还没有看到使用Wicket构建的非常复杂的UI.Wicket只能使用由预先包装的组件组成的简单UI.我用Wicket构建的每个UI都可以拥有更清晰的代码库,如果它不是在Wicket中完成的,它可以通过删除Wicket来更好地扩展.Wicket也不会给你带来很好的UI小部件.即使是Wicket的jQuery UI实现也不如直接使用jQuery UI.

在我的工作中阅读了成千上万行的Wicket代码后,我可以说Wicket代码基本上是意大利面条代码.如果你喜欢ulgy,不优雅,冗长,带有泛型和匿名内部类的代码,而不是Wicket就是你的东西.线路噪声量非常高.由于这个原因,代码库变得不易维护.如果您使用有缺陷的Wicket AJAX实现,则尤其如此.

Answer 3

几个答案声明wicket 无法动态创建组件树.说真的,我觉得你们在那里用不同的检票口;)

首先:Wicket是基于组件的,而不是随机的HTML生成器.

获得动态组件树实际上非常容易:

想要用另一个组件替换组件吗？使用Component.replaceWith(Component)(与空MarkupContainer结合使用非常有用)

需要一个动态变化的面板列表？把它们放在转发器中.

让组件消失？使用Componente.setVisible()

还有很多方法可以做到这一点.

所以,那些认为你不能做动态组件树的人,请提供一些例子,我很乐意讨论那些.

(如果你真的需要更加灵活,你可以从不同的来源制作Wicket加载标记.我从来没有为了构建动态树而做的事情,但能够从数据库或通过网络检索Markup)

Answer 4

我发现检票口非常有用,但这些都是我迄今为止发现的缺点:

• 稀疏文件:我还没有找到一个明确的指导检票口,即使有很大的文章和几本书
• Wicket URL默认是丑陋的
• 您无法动态定义组件树,因为您必须在HTML布局和Java代码中定义它们