You can basically have three time more users with Primeface than Icefaces (considering it is growing lineary)īecause Icefaces OOM my JVM very quickly without a cookie manager I did a very simple calculation on session size. Test setup : Core 2 Duo 3Ghz 64bits, 2GB dedicated to the JVM. Server loadI have created a simple unit test which executes 10 concurrent threads with a cookies manager. So the question is, why does it do that when we don't need them?
Knowing that I put an id only on the components i needed to update that means JSF autogenerate the other Ids by itself. The table contains ids and classes only on rows.īut what if the data changes on the server side (delete or add) ? An user action on the paginator doesn't update it. The paginator is updated on the client side. The Icefaces paginator block is quite big, more than the datatable block. The table contains ids and classes on all cells. Icefaces and Richfaces send the paginator and the table. Richfaces can gain 80KB by using JQuery min and be below 200KB. Icefaces and Richfaces don't used minified JS. Creating an unit test with HtmlUnit is quite simple and I did not met issue requesting Icefaces, Primefaces and Richfaces for the purpose of this article. Page size benchmarkI'm measuring the page size and the ajax response size with HtmlUnit. The datable is binded to an ajax paginator which display books 15 by 15. Test setupThe datatable will display a list of books with 3 columns : ISBN, author and title. I will focus on efficiency : page size, ajax request/response size, server load, and not on features. Import this article I will bench the datatables of 3 JSF2 components frameworks :
In this case we insert the code from source link. Now we need customized CalendarRender class inheriting. CalendarRendererĬomponent-family and render-type are properties from the component, this information is provided by Calendar class that has the properties that we set when we use the component. One of the files mentioned is the render class, this class inherited from , to know what is the render we can see it in the faces-conf file that is in pf jar or in the official documentation. In this case we can essentially override a configuration file with the class that we need change, in this case (remember, pf-calendar) CalendarRender class, I made a new class inheriting the original class but in my custom package of course. How can we do that? Well, as we know, each JSF component is composed by Java classes, configurations files(xml) and client side frameworks files(html code,/javascript/css), Frameworks like Primefaces resume all this files in one jar that we only use via maven or add to our classpath manually. The best solution I found was modify the functionality of Primefaces Calendar component outside Primefaces.jar. I googled this issue and found a solution :), but now I have another problem : How can I modify my application to add this functionality without modify original primefaces jar, or something like that. In this cases we can modify the original sources and override when classes are loaded by JVM, in my case I was working with Primefaces Calendar component, I needed add a mask to type a date/hour. In JSF there are powerful frameworks like PrimeFaces, IceFaces or RichFaces, they has strong components, however, sometimes we need a little more functionality than it provides us.