根据文档，它应该是世界上最容易使用的产品：
只需将icefaces.jar添加到应用程序中，我们就可以将Direct to Dom（D2D）渲染应用到页面中。
但即使是他们最基本的教程《ICEfaces入门2》似乎也不起作用。我下载了页面底部的代码，将其构建到WAR中，并将其部署到Tomcat6.0.32和Tomcat7.0.14中。我注意到的第一件事是，由于某种原因，复合组件不起作用：
/job-application.xhtml@39,78以下属性是必需的，但没有为它们提供值：id。
但这感觉更像是一个JSF问题（JSF2Composite组件必需属性抛出异常），所以我通过删除ID属性上的required来解决这个问题（尽管值上仍然有一个required="true"似乎没有问题）。无论如何，现在应用程序已部署。如前所述，当您单击Clear按钮时，它使用AJAX调用，最终在响应XML中获得表单的完整DOM。下一步是添加icefaces.jar，它应该添加Direct to DOM功能，以确保在响应中只发送差异：
ICEfaces 2将组件标记呈现到反映当前客户端视图的服务器端DOM（文档对象模型）。每次JSF生命周期运行时，都会进行DOM比较，如果有任何更改，则会将一组简明的页面更新发送回客户端，以应用于页面。我们称之为直接到DOM或D2D渲染。
然而，我得到了完整的表格作为回应，加上一些额外的ICEfaces行，比如：
<input name="ice.window" type="hidden" value="epgo74zmvc" />
<input name="ice.view" type="hidden" value="vs4ik661" />
很明显，ICEfaces正在做一些事情，但不是它承诺的那样。它实际上比普通的AJAX响应要长。因此，忽略了这实际上是一个更大的响应这一事实，我继续下一个承诺：
使用Direct to DOM渲染，我们不再需要嵌套在"清除"按钮中的f:ajax标记
听起来很直接，对吧？在页面上的示例中，他们只是将侦听器的EL表达式从f:ajax标记移动到h:commandButton标记。问题是方法签名不同。这应该是入门教程，但它并不关心实际引导您完成步骤。无论如何，我可以通过修改backingbean中clearForm方法的方法签名来解决这个问题，使其参数为now和ActionEvent，而不是AjaxBehaviorEvent。这样做，ICEfaces确实用AJAX操作取代了原本的整页操作，这真是太不可思议了，但我仍然有一种酸味。有人知道D2D为什么不起作用吗？我做错什么了吗？我还应该尝试使用ICEfaces吗？
为什么认为这是不正确的？
现在的情况是，您获得整个表单作为响应，以便在JSF生命周期中刷新服务器端视图和控制状态。当您使用ajax标记调用表单的部分更新时，实际发生的情况是它只会将DOM更新呈现给指定的组件。
AJAX确实在起作用，但它需要发送整个DOM，否则服务器端的逻辑可能会查看过时的数据。
这不仅仅是ICEFaces，还有JSF。事实上，这与ASP.NET的工作方式基本相似。请参阅此链接以了解JSF生命周期。
http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html
如果这不是你所期望的技术，我很抱歉。
ICEfaces完成DOM比较后，需要发送更新。为了告诉网桥的客户端部分将更新的内容放在哪里，ICEfaces需要指定祖先DOM节点的一些已知ID。服务器端渲染器只知道JSF组件的ID，包括自动生成的ID和手动指定的ID。它无法处理原始HTML标记。因此，对于您对fat更新的观察，我的最佳猜测是您使用了大量的HTML标记。
D2D和ICEfaces桥接的另一个特点是它不能添加或删除子元素。它只能完全替换ID可寻址标记。因此，如果您，即向表中添加新行，则整个表将被更新。
不过，我的知识是基于ICEfaces 1.8.2。