我们正在研究/调查 ICEFaces AJAX 推送技术的可能用途。想知道有没有人用过这个？他们面临哪些问题？以及对它的总体印象。
我们正在使用 Websphere 6.1 应用程序服务器 - 有任何实现此功能的人在 Websphere 上实现了它。
我们正在努力解决我们网站上的一个问题，我们希望用户能够对产品出价并实时获得出价。
我们目前正在使用 MyFaces + Tomahawk + Richfaces + 我们自己的一些组件，但如果需要，我们可以远离 Richfaces。
【问题讨论】：
如宣传的那样工作，在家和办公室经常使用它。
如果您使用 springsecurity 而不是不使用带有请求范围 bean 的 ondemandrender，则会丢失渲染之间的安全上下文。
Sessionrender 似乎没有这个问题。
最近我在实际的书缝中看到了一个很好的例子（虽然我的一些更好:-)），他们有一个关于冰面的小节。
sessionrenderer 比 ondemandrenderer 或 intervalrenderer 更容易使用，但没有那么多功能。
这是一个非常基本的例子。还使用了其他一些技术，我们的小项目以集成不同的技术而闻名。 http://web.me.com/cannonwc/Site/Blog/Entries/2008/11/7_An_example_of_ajax_Push.html
主站点上实际上还有更多内容
www.mooncatventures.com 和博客网站 www.mooncatventures.com/blogs
【讨论】：
首先我要说的是，Icefaces 是一款非常可靠的产品，它为我们节省了大量的开发时间，让我们在团队中没有大量 JavaScript 知识的情况下获得了一个良好的、现代感的 Web 应用程序。
也就是说 Icefaces 确实有它的缺点。许多很酷的功能，如部分提交，会导致客户端和服务器之间来回交流。状态保存在服务器上并反映在客户端中，这会在客户端和服务器之间产生大量来回流量。为了获得最佳性能，您将不得不深入挖掘并使用一些 JavaScript，而这正是您一开始就试图避免的事情。甚至验证也需要在服务器端完成，但我相信这是 JSF 的限制，而不是 Icefaces 的限制。
我也不理解 Icefaces 如何在看似次要版本之间更改组件 API。整个树组件在 1.7.2 和 1.8 之间发生了变化。树组件丑陋且有限，因此这是一个可喜的变化，但仍然如此。我们觉得 1.8 是强加给我们的，这让我想到了下一点。
Icefaces 将其非支持合同付费用户视为二等公民。在 Icefaces 1.7.2 和 1.7.2 SP1 之间，推送机制发生了重大回归，导致它在我们的应用程序中完全失败。唯一可用的修复是迁移到 1.8（其中有 API 更改）或使用 1.7.2-SP2，该版本仅适用于支持合同的客户。不要忘记 IceFaces 的目的是向您推销支持。 1.7.1 的唯一修复是手动修补版本的源代码，这并不可怕，但我希望会更好。
也就是说，我发现 IceFaces 是一个有用的产品，并且比 RichFaces 好得多，尤其是在文档质量方面。但是，如果我现在开始，如果你想要一个真正的开源产品，我也会看看 GWT，如果你想要一些非常丰富和厚客户端式的东西，我也会看看 Flex。有所有问题的活动我仍然会推荐 Icefaces，但它肯定会更好
【讨论】：
我已经简要地完成了一个原型。它像宣传的那样工作。将 AJAX 推送与此框架或任何其他框架一起使用时要考虑的重要事项是对 Web 服务器的影响。为了完成 AJAX 推送，客户端要么保持与服务器的持久连接，要么使用轮询，这两者都对高需求的 Web 应用程序有影响。我没有使用 Websphere 的经验，但您需要研究考虑到您的应用程序容器 (Websphere) 以及您将使用 Ajax 推送的页面上的负载，特别推荐什么。
我认为值得注意的是，还有其他框架在 AJAX 推送方面做得非常好和灵活——因为我总是倾向于开源解决方案（我们运行一个非常有效的 Apache/Tomcat/Spring/DWR 堆栈）我建议检查 DWR
【讨论】：
据我所知，DWR 使用的是 JavaScript 编程模型。使用 ICEfaces，您根本不需要 JavaScript。从维护的角度来看，它远比 AJAX 推送本身有趣。虽然在 1.8 版中，使用 AJAX 推送变得如此容易，以至于每个人都应该对其进行评估。
我将在即将出版的 ICEfaces 书中讨论一些细节 ;-)。
【讨论】：
我认为将 ICEfaces 与 RichFaces 混合使用是没有意义的。 AJAX 部分不兼容。 MyFaces 上的 ICEfaces 没问题。
瓷砖？你想保留瓷砖吗？这在使用与 ICEfaces 紧密集成的 Facelets 时没有任何意义。随着 Facelets 成为 JSF 2.0 的标准，无论如何考虑从 Tiles 更改为 Facelets 是个好主意。
【讨论】：
我们现在正在一个转换项目中使用它（将 JSF 应用程序从 IBM 的 Portlet JSF 实现移植到 Tomcat 上的 IceFaces），正如其他人所说，它像宣传的那样工作。我们做了很少的修改来适应实现的变化。到目前为止，我印象深刻。
【讨论】：
我们使用的是ICEFaces，开发丰富的应用程序非常容易。主要特性是可扩展的 Ajax Push 服务器。
ICEFaces 使用来自客户端的持久客户端连接，如果您的服务器不使用异步套接字，那么它需要为每个连接创建一个线程。作为 用户数量增加，线程上下文切换会对性能产生不利影响。好消息是，ICEFaces 已经支持来自（Glassfich、Jetty、Tomcat、JBoss）的 ARP（异步请求处理）。除此之外，该实现还附带了一个异步 HTTP 服务器，您可以在当前环境（例如 Websphere）中使用它。
“使用 ICEFaces，您根本不需要 java 脚本”。这在许多情况下都很棒，但有时您不想进行 ajax 调用来仅选中复选框或激活文本字段。添加 javascript 来做到这一点不是火箭科学，但它会让你的代码有点难看。
ICEFaces 确实将其合同付费用户视为一等公民（这是我在支付支持后所期望的：D），但您始终可以访问代码。很容易下载一个标签版本并用ant编译。
【讨论】：
您可以在没有 IceFaces 组件的情况下使用 Icefaces Push。我们将 Icefaces Push 与 Primefaces 组件一起使用。它可以一起工作，但并非所有组件都兼容，其中一些组件在执行推送时会引发 Javascript 错误。
【讨论】：