Monday, 31 August 2015

PrimeFaces vs RichFaces vs IceFaces in JSF - Part 2

Leave a Comment
In this tutorial we will compare three commonly used libraries which are used on the top of your JSF implementation. Richfaces, IceFaces and Primefaces.

Documentation

Richfaces 

Richfaces provides an online user guide which has been upgraded release by release while keeping the same schema. Unfortunately there are no additional tutorials about creating applications with Richfaces, some of them have been included in our site
According to my view on documentation: 
richfaces vs icefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces

Icefaces 

IceFaces: The documentation is quite extensive as it includes a large set of tutorials, examples and also, recentely added, video tutorials. On the other hand, it's a bit annoying that you need registration to access anything (libraries, tutorials) and it's a bit confusing that you keep popping between icefaces.org and icesoft.org when using accessing the site.
According to my view on documentation:
 icefaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces

Primefaces 

Again, Primefaces provides the most pragmatic approach, delivering a complete user guide which is itself a complete e-book about the platform. Some additional resources are included as well on the site.

A last consideration about the forums: since also the forums contribute to the suite documentation, both RF and IF have a longer history on the web and thus deliver a greater set of questons and answers. Primefaces is a bit younger but growing.
According to my view on documentation:
 primefaces vs richfacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesstarhalf

Amount of topics discussed in official forums:

icefaces ~20000
richfaces ~20000
primefaces ~13000

Open issues

Comparing issues between different products it's not so easy and could end up to comparing apples with oranges. We include a short view of all open issues leaving to the reader the final word ot it.
According to my view on open issues:
richfaces vs icefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces

As you can see from the following picture, Richfaces and IceFaces both use JIRA to track their issues so they are substantially comparable. While the amount of open issues is a bit larger in Richfaces, if we weight them by priority, about 93% of Icefaces issues are labeled as "Major", while Richfaces exibits "just" a 64% of Major issues. On the other hand RF has recorded some more Critical issues.
According to my view on open issues:
icefaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesstarhalf

Primefaces issues are tracked with google code and they are substantially less then the two other competitors (about 128 open issues), although, having a different lifecyle and number of releases, it's hard to compare them in an effective way.

According to my view on open issues:
primefaces vs richfacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces
(Note: we actually "denied" 5 stars to PF after finding an issue when delivering a large dataTable component.)

Core Features

Here comes the real meat. As a matter of fact all 3 suites are JSF 2 compatible stacks. Besides this, every suite enhanced the basic JSF 2 features with some additions: Let's see them all:

Richfaces 

On the the most interesting additions provided by RF is Ajax Push, named RichFaces Push. This allows you to perform realtime client side updates triggered via events from the server side. This is built around the Atmosphere framework which provides various transport mechanisms according to concrete browser support(Comet, HTML5 WebSockets). On the server events are managed by integrating Java Messaging Service (JMS). This provide enterprise level messaging integration all the way to the browser!

Usage of JMS at the back-end provides excellent integration with EE containers, and advanced messaging services. It also frees you from managing various entities at your business layer. If you are already using JMS for messaging in your application - you will just continue to send the same messages and you just need to to declare a4j:push at views which should listen that topics.

Another excellent addition provided by RF is an advanced queuing mechanism. JSF 2 provides a queuing mechanism out-of the box in order to sequence client side events with the built-in Ajax implementation. This queue is lacking in some very essential tuning options. The RichFaces a4j:queue provides these basic options in addition to other enhancements. There are two primary options available; 'requestDelay' and 'ignoreDupResponse'.
<h:panelGrid columns="2">
                    <h:outputText value="Request delay:" />
                    <h:inputText value="#{queueBean.requestDelay}" id="delay"
                        converterMessage="Delay field should be a number (Demo input disabled till this resolved)">
                        <f:convertNumber integerOnly="true" />
                    </h:inputText>
                    <h:outputText value="Ignore Duplicated Responces" />
                    <h:selectBooleanCheckbox value="#{queueBean.ignoreDupResponces}" />
</h:panelGrid>

Finally, another RF cool thing is Client Validation feature allows you to have true client side validation without writing a single line of JavaScript! The standard JSF validators and JSR-303 (bean validation) constraints will be available on the client side just by adding   to the desired inputs.
<h:inputText value="#{userBean.name}">
 
   <rich:validator/>
 
</h:inputText>
According to my view on core features:
richfaces vs icefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces

Icefaces 

A  big plus of ICEfaces is not having to declare 'AJAX update regions' on the page. With ICEfaces, incremental ajax updates to the page are automatic, as is component interaction. Behind the scenes, ICEfaces employs a technique called 'Direct-2-DOM' rendering, or D2D for short, to achieve smooth incremental page updates to the browser. ICEfaces stores a copy of the DOM, which represents the browser presentation state in a tree structure, on the server. When the user interacts with the page, an Ajax call may be made to the server, resulting in a change to the application state, which in turn will cause the page to be re-rendered on the server. 
Once the page is re-rendered on the server, and before the response is sent back to the browser, ICEfaces differs the old and new DOM trees to create a DOM update, which comprises the essential changes to the page which need to be sent back to the browser. 
These DOM updates, when received by the browser, are then evaluated and the browser DOM is reconstructed and updated with the necessary changes.

The benefit of D2D in that when ever any field value changed the dependent field update automatically, you don’t need to explicitly refresh the dependent block this saves lot of code and complexity an other important benefit we get is optimized server to client data transfer, only changed data is transfered from server to client.

Finally, also IF has a built-in Ajax Push, (named ICEpush) which adds the ability to push out ajax updates to groups of clients based on a server event, without the clients needing to request the update.
ICEpush relies on Servlet 3.0 standard ARP APIs. If they are not present in the deployment environment, normal thread blocking connections are used.

For clustered and high-availability deployments of Ajax Push-enabled applications the Enterprise Push Server (EPS) is required. It manages asynchronous blocking connections across the cluster and performs seamless fail over for mission-critical, high-availability deployments. EPS is available in ICEfaces Enterprise Edition.
According to my view on core features:
icefaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces 

Primefaces 

Although the strongest point of PrimeFaces is the component set, it also features various Add-ons simplifying Web and especially JSF development. Since Primefaces has in its DNA jQuery, most of this additions are based as Javascript call back methods.

One cool PF addition is the AjaxStatus feature which uses facets to represent the request status. Most common used facets are start and complete. Start facet will be visible once ajax request begins and stay visible until it’s completed.
Once the ajax response is received start facet becomes hidden and complete facet shows up.

Also PF has got its Ajax push, called PrimePush, which enables implementing push based use-cases powered by WebSockets using atmosphere.
Here's an example:
  is a PrimeFaces component that handles the connection between the server and the browser, it has two attributes you need to define. The first one (onmessage) defines the callback method, which is implemented as a javascript function.
<h:form>
  <h:outputText value="#{globalCounter.count}" styleClass=”display”/>
  <p:commandButton value="Click" actionListener="#{globalCounter.increment}" />
</h:form>
 
<p:push onmessage="handleMessage" channel="counter" />
 
<script type="text/javascript">
function handleMessage(evt, data) {
$('.display').html(data);
}
</script>
According to my view on core features:
primefaces vs richfacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefacesicefaces vs richfaces vs primefaces

<< Read Part 1                                                                                          

Read Part 3 >>

Read More