PrimeFaces 4.0 (and 5.0+) Client Side Validation

Posted on Posted in AngularFaces, JSF, simpliying JSF

Comparing the PrimeFaces approach to the AngularFaces approach on client side validation

These days I’ve been so busy implementing client side validations in my JSF library AngularFaces that I missed one of the most important features of the upcoming new version 4.0 of PrimeFaces: client side validation.

PrimeFaces 4.0 approaches client side validation from a slightly different angle than I did. By default PrimeFaces delays client validation until a button is pressed. That’s probably the behaviour most people expect. They already know it from traditional JSF applications and even most desktop applications. Most likely I’ll remove client side validation from AngularFaces. After all AngularFaces is just an extension of PrimeFaces 4.0, so there’s little point in offering the same feature twice.

Activating client side validation

By default, client side validation is disabled. It has to be disabled explicitly by setting the commandButton’s validateClient attribute:

<p:commandButton value="click me!" update="@form" 
                 validateClient="true"/>  

You also have to add a context parameter to the web.xml:

<context-param>
    <param-name>primefaces.CLIENT_SIDE_VALIDATION</param-name>
    <param-value>true</param-value>
</context-param>

The nice thing about PrimeFaces client side validation is you can combine it both with AJAX requests and with non-AJAX request. Thus your application can deal with slow networks and long waits caused by the latency. AJAX was meant to bring responsive applications to the intranet. In the greater internet this doesn’t always work. If you’re application is suffering from a slow network you now can activate client side validation and omit AJAX. It’s a small but important step towards writing a single page application in JSF. And if you need more, you’re always free to move on to AngularFaces1 :).

Evaluating JSR 303 bean validations

Update (Correction of an erroneous correction) 08.05.2014: A couple of days ago, I reported the following section covers a server side feature (which is sort of true). However, it’s also part of the Client Side Validation, as originally reported.

Basically PrimeFaces 4.0 reads JSR 303 annotations to evaluate them on the server. A comprehensive set of standard JSR 303 annotations are supported out of the box:

  • @Size
  • @Min
  • @Max
  • @DecimalMax
  • @Digits
  • @Pattern (to check regular expressions)
  • @Past
  • @Future

These annotations can also be evaluated on the client. PrimeFaces 5 requires you to activate a third switch to do so. You have to add another parameter to the web.xml:

<context-param>;
    <param-name>primefaces.TRANSFORM_METADATA</param-name>
    <param-value>true</param-value>
</context-param>

PrimeFaces 5 additions

TRANSFORM_METADATA also unlocks another feature concerning @Max, @NotNull and @Size(min=...). @Max sets the maximum length attribute of the input field, while the other two set the required attribute of the PrimeFaces component.

Custom validation

JSR 303 allows you to define your own validation constraint annotations. Unfortunately PrimeFaces can’t bring the user-defined validation code to the client. There is no Java-to-Javascript-compiler in PrimeFaces. But what it can do is to allow you to use custom JSR 303 annotation in your beans. All you have to do is to define a custom validator as a Javascript function and register it with PrimeFaces:

PrimeFaces.validator['Email'] = {  
    pattern: /\S+@\S+/,  
    validate: function(element, value) {  
        if(!this.pattern.test(value)) { 
            var msg={summary:"invalid e-mail address", 
                     detail: "invalid e-mail address"};
            throw msg;  
        }  
    }  
};  

This validator is called on every input field that is annotated by @Email on the server side.

Note that I simplified the PrimeFaces example as much as possible. The PrimeFaces showcase has a more sophisticated version that also reads the message bundle, localizing the message if needed.2

Validate as you type

At the beginning I wrote validation is delayed until the form is submitted. Actually that’s not the entire truth. You can add on-the-fly-validation by adding a facet to the input fields:

<p:inputText value="#{validationBean.integer}">  
    <p:clientValidator event="keyup"/>  
</p:inputText> 
<p:inputText value="#{validationBean.integer}">  
    <p:clientValidator />  
</p:inputText> 

The first input field is validated immediately as you type, while the second input field is validated when the field is left.

Conclusion

PrimeFaces 4.0’s clients side validation finally fills a gap that may not have been noticed by those who are working in a fast company intranet. Nonetheless many applications – and mobile applications in particular – may benefit significantly of the new feature.


Further reading:

PrimeFaces showcase demo
AngularFaces showcase demo
Visa card validator example by Rudy de Busscher


  1. Truth be told, at the time of writing AngularFaces isn’t a mature product yet. The ideas behind AngularFaces are still subject to change. I haven’t even decided which programming language I want to use. So maybe you should wait a little while before porting important production code from PrimeFaces to AngularFaces.
  2. To be honest, I didn’t test the internationalization yet.

3 thoughts on “PrimeFaces 4.0 (and 5.0+) Client Side Validation

Leave a Reply

Your email address will not be published.