JSF 2.0 与 Wicket 与 SpringMVC 3.x 的特殊要求

Posted 2023-02-23

【中文标题】JSF 2.0 与 Wicket 与 SpringMVC 3.x 的特殊要求

【英文标题】：JSF 2.0 vs. Wicket vs. SpringMVC 3.x for special requirements

【发布时间】：2011-07-23 14:28:12

【问题描述】：

在一个新的 Java EE 6 项目中为我的几个关键需求寻找一个可行的 web 框架，我在这里阅读了关于这个主题的许多线程，我终于可以将设想框架的数量减少到 JSF 2.0、Wicket 1.4（属于基于组件的）和SpringMVC 3（属于基于动作的 ）。

关于这些框架，我需要一些建议如果，也许如何实现以下要求：

最好分离设计器/编码器工作流程，以便设计器 - 最好 - 可以使用他们喜欢的工具（如 Dreamweaver）独立地制作 html、CSS、JS/jQuery 文件。

许多现有的（花哨的和动画的）jQuery 组件的轻松集成，例如这个Sliding Login Panel（可以看到一个演示here）。因此，需求实际上是现有 HTML+CSS+jQuery 代码的轻松集成，而且：

对于一个ui组件树，一个同步机制来同步客户端（通过JS/jQuery）动态变化的视图状态和服务器上对应的视图状态。

我想我会需要那个。例如，考虑上面的“滑动登录面板”在客户端通过 JS 可以更改“打开”或“关闭”。它的初始状态被编程为“关闭”，用户决定客户端始终保持打开状态。现在，当用户导航到某个地方并再次返回到该视图时，登录面板状态是无意的“关闭”而不是“打开”（因为这是它的初始状态，服务器端没有发生动态状态更新）。

因此，需要一个同步机制，对吧？？？

的最佳外部化（集中式）导航规则 (a) 任意页面间导航（静态导航规则），以及 (b) “向导式”导航（动态导航规则动态由 当前状态/结果）。

良好的性能（加载时间、服务器内存消耗、经验丰富的响应等）。

明显的问题是：

JSF2、Wicket 和 Spring MVC3 （很好）支持这些请求中的哪些，哪些不支持？

一般来说，有这个要求 - 因为我仍然不确定技术方面/后果： 在这种情况下，应该选择哪种框架类型（基于组件与基于操作）（即，应牢记哪些关键决策方面或“经验法则”）？

非常感谢您的建议和帮助。 马丁

【参考方案1】：

JSF：

在 JSF（Facelets）的模板语言中，这很容易。您只需编写常规 HTML 并仅为动态部分添加 jsfc 属性。请参阅***文章以获取快速示例：http://en.wikipedia.org/wiki/Facelets 使用 JSF 的复合组件真的很容易。只需将您的 jquery 内容放在一个 .xhtml 文件中，添加一个小标题，它就可以在任何地方作为组件重用。许多基于 jquery 的组件也可以直接使用 PrimeFaces JSF 擅长这种同步机制。同步通过定义明确且易于掌握的步骤数进行。基本上，这种同步机制或多或少是使用 JSF 而不是直接编写 jquery 的主要原因。 JSF 就是这样，它甚至被称为navigation rules。它们是在外部 .xml 文件中定义导航的强大机制。可以根据逻辑结果和/或在特定页面上发生的操作来定义导航规则。它们可以基于转发或重定向，有或没有额外参数。 JSF 整体表现非常好。它保持（保存）状态，因此这会花费您一些内存，但它足够聪明，只能部分保存（值与其原始值不同）。您还可以决定将此状态存储在客户端或服务器上。由于非常方便的view scope，支持逻辑使用的少量数据可以很容易地在请求之间缓存。这样可以避免您在每次请求后都访问数据库，并且可以大大提高性能。

JSF 真正闪耀的领域之一是它的组件模型。通过其复合组件概念，您可以很容易地自己组合组件。你也可以用Java创建组件，这有点复杂，但绝对不难。

因为 JSF 的组件模型是标准化的并且文档非常清晰，所以很多很多第三方都提供了现成的组件库。例如。 RichFaces、Primefaces、OpenFaces、IceFaces、Trinidad...这个列表几乎是无穷无尽的。

关于性能的一些额外说明。在比较您提到的三个 Web 框架中的任何一个时，差异可以忽略不计，并且根据经验，Web 框架并不是处理请求时花费大部分时间的地方。这几乎总是在数据库和 IO 中。

Web 框架可以帮助您轻松阻止访问 DB，但即使 Web 框架 A 在仅针对 Web 层的综合测试中比框架 B 快 10 倍，那么实际上您几乎不会注意到这一点，如果只有 5% 的请求时间花费在该框架中。

【讨论】：

Arjan，也感谢您对 JSF2 的帮助。就像 Wicket “子线程”一样，我仍然不清楚第 3 点。您能否进一步解释一下这种同步在 JSF2 中是如何工作的，或者至少给我指出一个代码示例，好吗？ ..同样，目标是实现一个 HTML+CSS+jQuery 组合，让它对客户端上的事件做出反应，并通知服务器端有关客户端动态发生的任何状态变化。对于我自己开发的组件，这方面我要怎么做？？？非常感谢。

@all：有人可以简要说明第 3 点（或任何相应的代码示例）吗？目前这对我有很大帮助。非常感谢您。

同步过程是JSF“生命周期”的意义所在。有很多可用的信息，但简而言之，在回发后它会恢复组件树，将（原始）请求值应用于组件，执行转换和验证，然后更新模型。在此之后有两个阶段，即调用应用程序（调用任何逻辑），最后触发视图的重新渲染。对于您的“同步”问题，尤其是“应用请求值”、“执行验证”和“更新模型”是相关的。这些都确保来自客户端的值被正确传输。

【参考方案2】：

检票口：

最好分开设计器/编码器工作流程：由于使用标准 HTML 和 CSS，可能。设计人员编辑 HTML，开发人员编写 Java。在 HTML 中，只有一些标记（wicket:id 属性）来定义动态组件的位置。 轻松集成jQuery：使用WiQuery，它将JQuery 组件与Wicket 集成在一起。使用 WiQuery，您还可以集成其他 JQuery 组件，这些组件可以回馈（WiQuery 是开源的）。 对于 ui 组件树，同步机制 [..]：Wicket 和 WiQuery 将在大多数情况下为您处理。 Wicket 在服务器端是有状态的，可以为您处理页面部分的刷新（内置）。 优化的外部化（集中式）导航规则：Wizards 的动态切换很容易（它只是 Java）。链接只指向您要显示的 Page 类，并为您处理点击时切换到该页面。 良好的性能：这完全取决于您的用例。 Wicket 可以集群化和扩展，因此对于 99% 的用例，您都有“良好的性能”。

一些一般性说明： 我真的很喜欢 Wicket 的组件模型。编写自己的组件和行为非常容易。 Wicket 的面向对象模型真的很强大。

【讨论】：

大安，非常感谢您的帮助。到目前为止，Wicket 似乎具有 (a) 最简洁的设计器/编码器工作流程分离，以及 (b) 直观的 prog。显然很有趣的模型（现在经常听到）。广告 3：[=client-to-server 同步机制] 由于我仍然无法想象这实际上是如何工作的，请您进一步详细说明从客户端到服务器的通知，或者提供一个示例，好吗？ ...我的意思是，有一个 HTML+CSS+JS 组件通过 JS func 调用对“onclick”事件做出反应，我想我需要用一些通知服务器 ajax 行为来装饰这个 JS func，不会我？

大部分情况下，您可以直接使用 Wicket，而无需编写自定义 javascript。添加一个 Ajax 事件行为 wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/… 并开始在 onEvent 方法中键入 Java。 Wicket 会处理剩下的事情。

对于高级的东西：每个行为都有一个 URL，你可以从你自己的代码中调用它。通过这个您可以与服务器端进行通信以管理状态。搜索“getCallbackUrl wicket”以查找更多信息。

顺便说一句，Wicket 的“缺点”可能是（如果我错了，请纠正我）： 1. 教授人数较少。组件库与 JSF2 相比。 2. Wicket 页面（通过“cwiki.apache.org/WICKET/websites-based-on-wicket.html”访问）似乎使用较少的动画组件（滑入/滑出面板、可重新定位和可折叠的面板、灯箱、dnd条目重新排序，...）。是因为比较少的可用性还是因为它们更难开发？您是否有一些链接到带有展示的 comp 库（类似于 PrimeFaces、RichFaces）？

查看 WiQuery 演示的示例：wiquery-plugins-demo.appspot.com/demo 和 code.google.com/p/wiquery-demos 我认为这与设计人员有关，而不是与框架支持有关。 Wicket 支持它，但如果设计不正确，您会让开发人员恢复到“更简单”的面板替换。