1

When reading information about PrimeFaces selector the following information can be found 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

I've tried to create really simple project like this :

        <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>

Then I debug on UIComponentBase findComponent() method. Suprisingly no matter which kind of selector I use (@(.ui-panel) or just panel2) it hits the method the same amount of times. In quoted text stands that it is better because component tree is not traversed on server side. But it looks like it is traversed no matter of usage primefaces selector. What is wrong in my way o thinking ? How PrimeFaces selector are better then standard ones ?

Artur Skrzydło
  • 1,135
  • 18
  • 37

1 Answers1

4

That blog article is more than 4 years old. JSF 2.2 was not available at that date. Retry with an older JSF version, particularly the one available at date of the blog. That's thus Mojarra 2.1.7 or older.

About two years ago, with release of Mojarra 2.2.5, Mojarra stopped traversing the component tree to validate an ajax client ID. This has some benefits: 1) saving performance exactly as described in that blog and 2) referencing a specific ui:repeat or h:dataTable iteration round as ajax client ID. The disadvantage is however that you will get no feedback whatsoever when you typo'ed the client ID and it appears to not exist in the tree at all. Before Mojarra 2.2.5, you'd get a clear exception on that.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I was trying to run code from PrimeFaces Cookbook Second Edition, which has primefaces 5.2 and Mojarra 2.2.8 version. It is available under this [link]https://github.com/ova2/primefaces-cookbook. In this book also the same information, like from the mentioned primefaces blog, can be found. So even know it looks like this information is not true. – Artur Skrzydło Oct 07 '16 at 17:35
  • I see that I made some mistake, because I've deployed my webapp on server with it's own jsf implementation and during debuggin in eclipse it has switched between two versions of UIComponentBase classes. Conclusion is that after retest on Mojarra 2.1.7 Prime Faces Selectors works as expected. Without them it travers the component tree, with them - not. From you answer I conclude that this advantage of PFS is not so important when I would like to use release of Mojarra 2.2.5 and higher, because it doesn't traverse component tree by default. Thank you for your explanation – Artur Skrzydło Oct 08 '16 at 14:04
  • Performance concern is negligible anyway. I have found PFS very useful in abstracting away multiple client IDs by a single self-explanatory style class. E.g. `update="@(.updateOnChangeAddress)"`. – BalusC Oct 08 '16 at 14:06
  • yes, indeed, i consider it as a second advantage of usage PFS – Artur Skrzydło Oct 08 '16 at 14:08
  • @BalusC Sir can you help http://stackoverflow.com/questions/40533116/sort-by-unhide-the-column-again – AI. Nov 10 '16 at 17:45