Tag Archives: OmniFaces

Newsflash: OmniFaces 2.0 released

OmniFaces 2.0 has been released today (Nov 24, 2014).

What is OmniFaces?

For those who don’t know OmniFaces yet: OmniFaces is… different. It’s a JSF library that doesn’t focus on providing GUI widgets. Instead, it integrates into your existing JSF ecosystem and adds functions lacking in JSF. OmniFaces 2.0 offers 90 components, give or take a few, most of them dedicated to non-GUI components. My favorite OmniFaces features are the CombinedResourceHandler, which accelerates the delivery of most JSF pages tremendously, the SelectItemsConverter which makes JSF comboboxes a lot less scary and the FullAjaxExceptionHandler, which make exceptions occurring during an AJAX request visible.

What’s new in OmniFaces 2.0?

Many things. In this article I’ll focus on two interesting new features: Bean validation at class level and simplified display of images.

JSF 2.0 added support for the Bean Validation API (aka JSR 303). Sad thing it didn’t support the API completely. Neither does the current version, JSF 2.2. To fill the gap OmniFaces adds <o:validateBean />. Among other things, this allows you to implement cross-field validations. Add <o:validateBean value="#{myBean}"> to your form to have the bean validated. In my opinion, this solution still doesn’t fulfill the promise of JSR 303 (which says a simple annotation to the class does the trick), but to be fair, it’s not easy to meet the requirements of the JSF lifecycle. The JSF specification requires that invalid values are not written to the bean. Therefore framework developers have to copy the bean to implement things like class level or cross field validation. By this measure OmniFaces does a pretty good job. Read the full story here.

Have you ever tried to display an image stored in a database? That’s one of those things that are simple using basic servlets, but horrendously difficult using JSF. <o:graphicImage> saves you from learning about ResourceHandlers. All you have to do is do define a CDI bean returning the image as a byte array:

@Named
@ApplicationScoped
public class MyImage {
    public byte[] getImage() {
        return /* the image as byte array */;
    }
}
<o:graphicImage value="#{myImage.getImage()}" />

See more details explanations and examples at the OmniFaces showcase on o:graphicImage.

Increased requirements

Talking of which – yes, I said you need a CDI bean, and I meant it. OmniFaces 2.0 requires Java 1.7, JSF 2.2, EL 2.2, Servlet 3.0 and CDI 1.1. Spring users have to stick with CDI 1.10. The good news is OmniFaces is going to supports the 1.x branch for a while, but they don’t intend to implement the new features into the 1.x branch.

Dig deeper

OmniFaces 2.0 released! by Arjan Tijms
OmniFaces 2.0 released! by OmniFaces lead Bauke Scholz (aka BalusC)
OmniFaces showcase

Why JSF 2.0 Hides Exceptions When Using AJAX

I always wondered why my application tends to hide exceptions. An exception occurs on the server side without getting visible on the client side. The client doesn’t show any reaction at all. Often you need a tool like FireBug to become aware there’s an error.

It took me a while to realize this only happens with AJAX requests, and that this is a well-known behavior in the JSF community. However, there’s at least one excellent book (also available at jsfatwork.irian.at) which doesn’t mention the problem. So maybe it’s worth spending a couple of minutes to write a small article on an old topic.
Continue reading