Setting the severity level on ExtVal Property Validation constraints

To set a severity level to an ExtVal Property Validation annotation, we should use
the parameters attribute of the annotation instead of payload. We should also
import another ValidationSeverity class. If we had used ExtVal annotations
instead of JSR 303 annotations in our Employee class, the salary variable declaration
would now look like this:

	package inc.monsters.mias.data;

	import org.apache.myfaces.extensions.validator

			.core.validation.parameter.ViolationSeverity;

	// Other imports are hidden for brevity.

	public class Employee implements Serializable {

		@LongRange(minimum=100, parameters=ViolationSeverity.Warn.class)

		private int salary;

		// All other variables and methods are omitted.

	}

Notice the changed import (the first highlighted part of the snippet) and the ExtVal
@LongRange annotation that replaces the @Min annotation from the JSR 303 example.

	The use of the parameters attribute in this example is just a convention.

	Unlike the payload attribute in the Bean Validation example, the

	attributes of ExtVal annotations are not fixed. ExtVal scans all of the

	attributes of its annotations by type. This means that any parameter with

	the ViolationSeverity.Warn type—or any other type implementing

	the ValidationParameter interface—will be interpreted as metadata

	by ExtVal.

Setting the severity level on any constraint

Although the Bean Validation annotations, as well as the ExtVal annotations,
have special attributes that can be used to add metadata such as the severity level,
other annotations that are used to define constraints may not have such facilities.
For these cases, we can use the Virtual Meta Data add-on , which is a part of the
Advanced Meta Data add-on bundle. See the Extending ExtVal with add-ons section
for download and installation instructions for this add-on.

The only other constraint type that is currently supported out of the box by ExtVal
is the JPA constraint. As JPA constraints are derived from database constraints, it
doesn’t make sense to bypass the violation of such constraints. So, by default, ExtVal
will not allow this even if we set the severity level to warning. However, we can set
the severity level to “fatal” to be able to mark error messages from JPA constraints
as more important than other error messages that are marked with level “error” by
default. This does make more sense as an example in this case.

The next example shows the lastName variable, annotated with the JPA @Column
annotation with its nullable attribute set to false. This effectively makes the
lastName variable a required field. To mark the violation of this constraint as more
important than other violations, we want to set the severity level to “fatal”. As
the @Column annotation does not have an attribute to set extra metadata, we use
the @VirtualMetaData annotation from the add-on to set the metadata as follows:

	package inc.monsters.mias.data;

	import org.apache.myfaces.extensions.validator

		.core.validation.parameter.ViolationSeverity;

	// Other imports are hidden for brevity.

	public class Employee implements Serializable {

		@Column(nullable=false)

		@VirtualMetaData(target=Column.class,

				parameters=ViolationSeverity.Fatal.class)

		private String lastName;

		// All other variables and methods are omitted.

	}

Note that the attributes of the @VirtualMetaData annotation accept exactly the same
types as the attributes of all ExtVal Property Validation annotations. That’s why we
can use the same ValdationSeverity class in this case. The target attribute is needed
to link the @VirtualMetaData annotation to the @Column annotation.

Summary

This chapter introduced MyFaces Extensions Validator, or ExtVal for short. After the
installation of ExtVal, we saw that no configuration is needed to get started, based
on standard JPA annotations. After that, we had a look at the extra annotations that
ExtVal adds to facilitate more validation options and to enable cross validation. We
saw how we can combine ExtVal with custom JSF validators. We also looked into
creating custom error messages. We saw how we can customize and extend ExtVal
in various ways. And finally, this chapter showed us how we can integrate ExtVal
with JSR 303 Bean Validation.

This chapter has covered only the basics of what is possible with ExtVal. As ExtVal
provides a very extensible and fl exible infrastructure, the possibilities are virtually
endless. More information can be found on the weblog of Gerhard Petracek, the
lead developer of ExtVal, at http://os890.blogspot.com/. Another resource of
additional information is a series of articles about ExtVal on JSF Central. The first
article of the series can be found at http://jsfcentral.com/articles/myfaces_
extval_1.html. The easiest way to find the other articles in the series is to just
replace the 1 in the URL by a higher number. The series currently consists of three
articles, but more may be added in the future.

The next and last chapter of this book will introduce some best practices for using the
various MyFaces libraries.

Comments

comments