Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News OmniFaces: A Utility Library for Java Server Faces

OmniFaces: A Utility Library for Java Server Faces

Leia em Português

This item in japanese

OmniFaces is a utility library attempting to ease JSF development for Enterprise applications. It was created by Bauke Scholtz (a.k.a. BalusC) and Arjan Tijms. They are regular contributors at the popular Stack Overflow Q/A site and implemented OmniFaces after noticing some common JSF 2.x problems in the Stack Overflow questions. Despite the name, OmniFaces is NOT another JSF implementation. Instead, it complements existing JSF libraries with several helpers and solutions to specific problems. The live showcase is actually based on PrimeFaces.

The OmniFaces library has an extensive list of features that include:

  • Highlighting fields that failed validation
  • Importing constant values into EL scope
  • Automatic conversion of model objects in drop-downs and other select components
  • Multi-field validators, for "all or none", "all equal", "one or more", "all in order" and "unique" validations
  • HTML5 render kit which adds support for several HTML5 specific attributes to UIForm and UIInput components
  • Full Ajax exception handler
  • Tree with full custom markup per level (useable for various recursive use cases)
  • Collections of EL functions for dealing with arrays, conversion, dates and strings
  • GZIP compression filter for HTTP responses
  • Include Servlets and JSP pages in Facelets

InfoQ contacted the authors of OmniFaces for some clarifications, and we started by talking about their reasons for creating the library. They made the point that JSF lacks an equivalent of Apache Commons or Guava, so that "every company or JSF web application developer develops their own set of utilities, which is time consuming and error prone when it's the 1st time." They also pointed out that there are a number of recurring problems in JSF applications, such as "resetting invalid but unprocessed input components before an Ajax update, or having a full Ajax aware exception handler which uses standard web.xml error page mechanisms, or the need for a generic converter for dropdown items" which can be provided by the OmniFaces library.

Since there are a large number of pre-existing JSF libaries, including PrimeFaces, RichFaces and ICEFaces, we went on to talk about how OmniFaces compares with those

OmniFaces does not offer any really visual components with custom renderers (so that the fancy look'n'feel and enhanced behaviour can be achieved by generated CSS/JS). Instead the components and TagHandlers of OmniFaces enhance the existing core JSF components and TagHandlers like f:viewParam, f:converter, f:validator, h:form and h:outputLabel.

Besides components and TagHandlers, OmniFaces also offers a lot of reusable utilities to make JSF development easier without the need to reinvent the wheel. This is not offered by any of the mentioned libraries.

So whilst PrimeFaces, RichFaces and ICEFaces all seem to primarily focus on visual components (widgets), OmniFaces is more about utilities and workarounds for shortcomings or problems in JSF. You could maybe say those first three are JSF Component libraries, whilst Omnifaces is a JSF Utility library.

InfoQ: Could you enhance one of the existing JSF frameworks instead of creating a new one?

Theoretically, we could, but we prefer not to. We intend to develop a utility library which is useable on every JSF web application. We have however one RichFaces specific workaround in the ResetInputAjaxActionListener due to an unresolved bug in RichFaces' implementation of the PartialViewContext.

InfoQ: What were the recurring problems/questions that you saw on Stack Overflow?

A few of them were the need for a markup-less tree component, the awkward approach of using IE conditional comments, the need for an f:selectItems converter which just converts the provided items instead of doing expensive DAO calls, the need to reset input fields which are invalidated in a previous Ajax request but need to be updated in the current Ajax request, an Ajax aware exception handler, well, almost anything.

At the moment our roadmap is pretty much determined by the problems that we see people having with JSF. This means that we don't really sit down and set out a plan of things we think will be great, but react to real life problems. This way of working is not set in stone, and we may introduce some features at some point that we ourselves believe in, but at the moment it's all about solving people's problems.

InfoQ: Anything else that you would like to add for InfoQ readers?

One thing that can maybe get some extra emphasis is that we in no way want to be a competitor to PrimeFaces (and RichFaces). On the contrary, we're both a big fan of PrimeFaces and use it on a daily basis for the business applications we're involved with. That we build the OmniFaces showcase application with PrimeFaces and clearly mention that fact on its top right corner is maybe telling enough.

OmniFaces has just released version 1.0 (Update: version 1.1 is now available with Maven support). For more information see the blog, Javadoc and the tag library information.

Rate this Article