On many discussion forums frequented by developers, the question that crops up often is “if you were starting a Java Web project from scratch, what technology would you choose?” There are so many parameters involved in making such a choice that the questioner is usually either someone fairly new to IT or it is really just a leading question and they are waiting for an answer that will allow them to preach their personal choice (almost always one they profit from).

I personally have many preferences that come before JavaServer Faces (JSF), and I’m well aware that I also happen to be in the minority with that view point at this time. Given that JSF is becoming more and more prevalent in J2EE / Java EE Web applications, I am constantly on the hunt for ways to make working with it more productive (something that I am not alone in). Most recently my compass (which points due Lazy most days) led me to PrimeFaces.

PrimeFaces vs. the Competition

A search on Google for PrimeFaces includes the following:

This shows us that PrimeFaces is poised as an alternative to ICEfaces, MyFaces and OpenFaces … and someone has done a real good job of promoting their blog. The SEO aspect aside, how does PrimeFaces stack up against more well-known libraries that Google finds to be similar?

On the one hand, PrimeFaces is much easier to use than the common competitors. The syntax is very straightforward, such as this example of using the accordianPanel tag (taken from Accordion Panel – Dynamic page on PrimeFaces.org):

On the other hand, this simplicity is achieved by targeting a very specific environment, i.e., JSF 2.0 with Facelets. As someone who often needs to get up to speed quickly on new products it was a bit disappointing that these prerequisites are not mentioned on either the Getting Started or Why PrimeFaces pages of the project site. While the JSF 2.0 requirement is covered on the FAQ page, the need to use Facelets is not. It would have taken at least two hours less to get a satisfactory Hello World PrimeFaces page up if this fact had been noted more prominently. Once this quirk was discovered, a new PrimeFaces page from scratch took only 15 minutes to get up and running in Eclipse (more on Eclipse later).

The inverse square law of complexity versus flexibility still holds true, and so long as the choice is based on requirements rather than perceived costs, PrimeFaces is a serious contender. Simple generally (though not always, and I'm sure you can think of your own example) leads to increased productivity. If you are not already skilled in Facelets, the paradigm shift needs to be weighed as a factor, balanced by how extensively you will be using the features offered by PrimeFaces and the expected life-span of your application (applications that will be used long-term also tend to be enhanced often).

Getting Started with PrimeFaces: The Two-Step Approach

Being a standards-based library, PrimeFaces is basically plug-and-play, so long as you consider using JSF UI libraries "play". PrimeFaces requires JSF 2, which many assume includes JSTL (even though it is a separate archive), so two steps assumes that you have jsf-api-2.0.3.jar, jsf-impl-2.0.3.jar and jstl-1.0.2.jar already installed in your application. This leaves our two steps as:

1. Place the PrimeFaces JAR in WEB-INF/lib (RC 2.2 at this writing)
2. Add *.xhtml as a node to the Faces Servlet in web.xml

Sure, if your project was already configured for XHTML it would only be one step, but who ever heard of a one step installation?

Yes, You Can Use PrimeFaces in Eclipse

For the Eclipse user, PrimeFaces will work into your day-to-day routine, though the initial integration requires slightly more skill than installing of the many ready-made plugins. The first step is to add PrimeFaces as a library in your workspace:

Then, when you create a project, add the appropriate facets:

If you aren't familiar with Eclipse facets, they add the libraries for you, which you can still do yourself if you'd like. You can tell the difference by looking at your project Java Build Path.

Finally, if you want auto-complete, associate .xhtml to JSP in Content Types:

Documentation? I Don't Need No Stinkin' Documentation!

One major difference between PrimeFaces and other JSF libraries is the ready availability of documentation. Usually, the documentation is included in the binary download, or available online. In the case of PrimeFaces, you only get any documentation (past an 18 page teaser) by buying it. At first I was taken back to the early days of JBoss where the free manual had just enough to frustrate the average developer but the JBoss team was kind enough to sell a book that was both readable and helpful. However, after breaking my habit of only using Google, I found a "hidden" page (I still cannot find a link on the PrimeFaces website to this page, so I call it hidden). Here is an index of features, each a hyperlink to a very easy to follow example of using the given tag. So now I have decided that the PrimeFaces team is simply pricing their wares inversely to customer intelligence, meaning the dumber you are the more you pay…and I almost paid the first premium, so all bragging rights for me are lost.

So, hopefully I have made it clear that compared to most JSF solutions PrimeFaces is a nose ahead competition in simplicity. Still, I am constantly reminded that JSF developers are interested in the complex and hate to use any HTML tag in a page. A perfect illustration of this is the PrimeFaces "separator" tag, which does absolutely nothing more than to take the style parameter and write a Horizontal Rule HTML tag with the exact same value. In other words, a conscious choice was made to prefer using:

instead of:

for no discernible reason other than to avoid the stigma of having used HTML to send HTML to the browser. Dogma can be both enlightening and limiting, no matter what form it takes.

Still, No Open Source Project is Perfect

Another minor nit that must be picked. None of the examples I found online included "", yet none will work without it. I discovered this necessary little nugget. Running a view source after making that change it is easy to see that the tag is required by PrimeFaces to set various client-side imports. On the one hand, it is neatly done the way they have built in the necessary technologies using custom tags to generate the scripting and mark-up languages many developers refuse to learn. On the other other hand, they have buried the CSS in a JAR, making it more difficult for the non-Java programmers who usually customize the CSS to do so. And with the CSS class names predefined in the code, developers must first render the component and then style it. Not a technical issue, but definitely a logistic issue as most projects have the styling done first, then the dynamic code written afterward.

Conclusion

PrimeFaces is a good choice for a lightweight JSF library for green field projects where JSF is the chosen technology as well as the few in-production projects that may fit all of the prerequisites (JSF 2.0 with Facelets).

For the average JSF advocate who views Java code, HTML, CSS, or JavaScript in JSPs with the same horror a school principal has about beer in the cafeteria vending machines, PrimeFaces is full of solutions to everyday UI chores. In fact, PrimeFaces even shuns those pesky JSP files as it only works with Facelets.

For long-time Web developers this paradigm shift away from all of the familiar technologies makes PHP and .NET look suddenly attractive. On the other hand, we always knew that XML was going to take over the planet, which puts PrimeFaces securely in the court of the new regime.