JSF Under the Hood—Part 2 - JSF and HTML5 - page 79

<h:commandButton action="#{testBean.proceed}" value="Proceed"/><br/>
<h:messages style="color: red"/>
</h:form>
</h:body>
</html>
As shown in the bolded lines, in the test page, there is an input text which uses the EmailValidator using the
<f:validator> tag. The <f:validator> tag is a core tag that is mainly designed in order to avoid creating a TLD
for every custom validator. Passing the ID of the custom validator which is defined in the @FacesValidator
annotation to the validatorId attribute of the <f:validator> tag will attach the custom validator to the parent
EditableValueHolder component.
Figure 3-4 shows a validation error that will be displayed when the user enters an invalid e-mail that does not
cope with the e-mail format requirements.
Figure 3-4. EmailValidator error message
Figure 3-5 shows the behavior of the EmailValidator when the user enters valid e-mail information that copes
with the e-mail format requirements.
Figure 3-5. EmailValidator valid form
JSR 303 Bean Validation with JSF
JSR 303 Bean Validation was introduced in Java EE 6 in order to empower building validation in Java enterprise
applications. JSR 303 comes with built-in validators (constraints) such as @NotNull , @Min , @Max , @Past , @Future ,
@Size , etc., and it also allows creating custom constraints on the application domain model (or generally on POJO).
Adding to the JSF built-in and custom validators, and since JSF 2.0, there is default integration between JSF and
JSR 303 Java Bean Validation APIs. In the next subsections, this sort of integration will be illustrated in a sample
subscriber application.
In the subscriber application, the user can save (his/her) name, address, and e-mail for subscriptions, as shown
in Figure 3-6 .