为什么使用 Primefaces 选择器在服务器端有更好的性能？

Question

阅读有关 PrimeFaces 选择器的信息时，可以找到以下信息 primefaces blog

There is less CPU server load compared to regular referencing because JSF component tree is not traversed on server side to find a component and figure out the client id as PFS is implemented on client side by looking at dom tree

我试过像这样创建非常简单的项目：

        <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 选择器如何优于标准选择器？

Answer 1

该博客文章已有 4 年多了。那时 JSF 2.2 还不可用。使用较旧的 JSF 版本重试，尤其是博客发布时可用的版本。这就是 Mojarra 2.1.7 或更早版本。

大约两年前，随着 Mojarra 2.2.5 的发布，Mojarra 停止遍历组件树来验证 ajax 客户端 ID。这有一些好处：1) 完全按照该博客中的描述节省性能，以及 2) 将特定的 ui:repeat 或 h:dataTable 迭代轮引用为 ajax 客户端 ID。然而，缺点是当您输入错误的客户端 ID 并且它似乎根本不存在于树中时，您将得不到任何反馈。在 Mojarra 2.2.5 之前，你会得到一个明显的例外。

另请参阅：

How do PrimeFaces Selectors as in update="@(.myClass)" work?
How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"

为什么使用 Primefaces 选择器在服务器端有更好的性能？

Why usage of Primefaces selectors has better performance on server side?

primefaces

jsf-2.2

另请参阅：