为什么使用Primefaces选择器在服务器端有更好的性能？
当阅读有关PrimeFaces选择器的信息时，可以在PrimeFaces博客中找到以下信息
与常规引用相比，CPU服务器负载更少，因为PFS是通过查看dom树在客户端实现的，所以不需要在服务器端遍历JSF组件树来查找组件和计算客户端id
我试图创建一个非常简单的项目，像这样：
<h:form>
<p:panel id="panel2" header="Second panel">
<p:outputLabel for="address" value="Address"/>
<p:inputText id="address" required="true"/>
</p:panel>
<p:commandButton process="@(.ui-panel)" update="@(.ui-panel)"
value="Process and update all panels"/>
</h:form>
然后在UIComponentBase findComponent（）方法上进行调试。令人惊讶的是，无论我使用哪种选择器(@(.ui-panel)还是仅使用panel2)，它都对该方法进行相同次数的访问。在引用的文本中，它更好，因为组件树不在服务器端遍历。但它看起来像是遍历不管使用primefaces选择器。我的思维方式出了什么问题？PrimeFaces选择器如何比标准选择器更好？
共有1个答案
那篇博客文章有4年多的历史了。当时还没有JSF2.2。重试一个较旧的JSF版本，特别是博客日期可用的版本。这就是Mojarra2.1.7或更高版本。
大约两年前，随着Mojarra2.2.5的发布，Mojarra停止遍历组件树以验证ajax客户机ID。这样做有一些好处：1）完全按照博客中的描述保存html" target="_blank">性能；2）将特定的ui：repeat或h：dataTable迭代循环引用为ajax客户机ID。但是缺点是，当您键入客户机ID时，您将不会得到任何反馈，而且它似乎根本不存在于树中。在Mojarra 2.2.5之前，您会得到一个明显的例外。
- update=“@(.MyClass)”中的PrimeFaces选择器如何工作？
- 如何查找ajax更新/呈现组件的客户端ID？找不到从“bar”引用表达式“foo”的组件
-
我的Kubernetes集群运行在谷歌云下。我有部署运行端口443和LoadBalancer公开它到互联网。 我是这样创建的： 运行此命令后，loadbalancer将指向部署。现在，我创建了，并希望更改loadbalancer以指向新的部署()。 注意：删除和重新创建部署是释放外部IP地址，我想避免它。 如何在不丢失外部IP的情况下修补现有服务以指向另一个部署？
-
问题内容： 我正在编写一个脚本，该脚本应该在一堆服务器周围运行，并从其中选择一堆数据，包括本地服务器。选择所需数据的SQL非常复杂，因此我正在编写临时视图，并使用OPENQUERY语句获取数据，因此最终我最终循环了如下语句： 但是，我听说在本地服务器上使用OPENQUERY是一种皱眉。有人能详细说明为什么吗？ 问题答案： 尽管查询可能返回多个结果集，但OPENQUERY仅返回第一个结果集。 OPE
-
问题内容： 我找到了一个响应式电子邮件模板的示例，其中有诸如此类的CSS选择器： 如果与以下内容完全相同，为什么要使用此语法： 它对移动浏览器或其他任何影响吗？ 问题答案： 该语法是属性选择。 这将选择带有的任何标签。但是，它 不会选择具有的（例如。它仅与_ 该属性完全匹配。 您可能需要阅读必须记住的30个CSS选择器。对于任何有前途的Web开发人员来说，这都是无价之宝。
-
问题内容： 我正在编写一些返回JSON数据的Web服务，这些用户有很多用户。 与仅使用go http服务器相比，在服务器前端使用Nginx有什么好处？ 问题答案： 这取决于。 开箱即用，将nginx放在前面作为反向代理将为您提供： 访问日志 错误日志 轻松终止SSL SPDY支持 gzip支持 在几行中为某些路由设置HTTP标头的简单方法 非常快速的静态资产服务（不过，如果您要使用S3 / etc
-
问题内容： 我在没有选择器的情况下在Kubernetes的服务中苦苦挣扎。群集通过kops安装在AWS上。我有一个带有3个Nginx Pod的部署，暴露了端口80： 创建部署后，我记下了IP地址： 并创建了一个服务于IP地址的服务： 服务已成功创建： 不幸的是，我尝试通过服务从相同名称空间的另一个Pod连接到Nginx失败： 我可以直接成功地连接到Nginx Pod： 我注意到我的服务没有任何端点
-
问题内容： 我刚刚学会了最近的反应，打算将其用于下一个项目。我已经遇到过几次反应服务器端渲染，但是想知道为什么在“现代时代”我们仍然需要它。 在本文中，它认为通过服务器端渲染，用户不必等待从CDN或其他地方加载这些js即可看到初始静态页面，并且该页面将在js到达时恢复功能。 但是在使用webpack生产配置和gzip构建之后，整个捆绑包（包括react，我的代码和许多其他东西）仅占用40kb，而我