我目前正在开发一个大量使用 JSF 和 IceFaces 的网络应用程序。我们已经讨论过转移到另一个表示层,我想我会把讨论带到 SO 中,看看专家们是怎么想的。
我很好奇是否有人可以权衡各种 Java 表示层技术的优缺点。如果您只与一个人合作过,请说出您喜欢或讨厌它的原因。如果你和几个人一起工作过,请给出你对它们如何相互叠加的印象。
我们正在考虑的技术是:
- 冰面
- JSF(没有 IceFaces)
- GWT(谷歌网络工具包)
- 便门
- 挂毯
如果我的清单中缺少任何内容,请告诉我。
谢谢!
我目前正在开发一个大量使用 JSF 和 IceFaces 的网络应用程序。我们已经讨论过转移到另一个表示层,我想我会把讨论带到 SO 中,看看专家们是怎么想的。
我很好奇是否有人可以权衡各种 Java 表示层技术的优缺点。如果您只与一个人合作过,请说出您喜欢或讨厌它的原因。如果你和几个人一起工作过,请给出你对它们如何相互叠加的印象。
我们正在考虑的技术是:
如果我的清单中缺少任何内容,请告诉我。
谢谢!
我的观点对 Wicket 有很大的偏见,因为在多次绊倒 JSP 矿井之后,我已经使用了一段时间。
检票口优点:
检票口缺点:
Form.onSubmit()
)需要大量的子类化或匿名方法覆盖,以便轻松注入行为。这部分归功于 Wicket 强大的基于事件的设计,但不幸的是,这也意味着 Wicket 很容易使代码混乱。随机缺点:(也就是说,我没有使用过,但这些是我的意见和/或我听说过的事情)
我已经将 GWT 用于几个小项目。这里有一些我喜欢它的地方:
我不喜欢的东西:
我要问的最大问题是为什么要更改表示层?这是一个非常昂贵的成本,我可以看到一种技术的好处超过了其他技术的成本,就像改变的成本一样......
简而言之:
= JSF =
优点:
缺点:
= 检票口 =
优点:
缺点:
条纹呢?
我的选择是Wicket。已经使用过它,并且具有出色的可重用性。它拥有最活跃的论坛/邮件列表之一。作为一个问题,它会在几分钟内得到回答。它对 AJAX 有很好的支持。归因于 Wicket 的常见缺点之一是陡峭的学习曲线。好吧,这些是现在不再有价值的老年弊端之一。
JSF:最好远离它。另一个在 JSF 上开发项目的团队现在正在考虑在我们成功后转向 Wicket。
@Megadix:就像你说的文档一开始很差,但现在没有了。Wicket 的开发人员编写了一本名为 Wicket in Action 的优秀书籍。网站上提供的示例代码也是一个很好的开始和学习的地方
我想知道您是否有一个与 Web 客户端不同的服务层,Web 控制器只需调用它来完成他们的工作。
如果这样做,Web UI 技术的选择可以与后端解耦。如果它作为合同优先的 Web 服务公开,您可以让不同的应用程序共享它。只要您的客户可以发送和接收 XML,他们就可以与您的服务进行交互。想要切换到 Flex?不用担心 - 将它指向服务并呈现 XML 响应。
请参阅我对 Wicket 和 Tapestry 5 的比较:Apache Tapestry 和 Apache Wicket 之间的区别。