The capability to invoke custom validation methods

Execution of J-Unit testcases concerning the mhs_dev.validationFrameworkFrom now on, I offer you my validation framework in version 1.0.0.c. I hope this version will become the final release.
So which changes did it receive:
There is just one feature I wanted to build in and become part of the final release: The capability to invoke custom validation methods. After nearly 40 downloads of version 1.0.0.b, 10 downloads of version 1.0.0a and two proposals from interested readers, the only business issue they told me about, was the fact that it is not possible to extend the framework for custom purposes of special validations i.e. “does this credit card number already exist in our database?”. Therefore, you are now able to invoke your own validation methods.
But there is even one thing I removed: The web-support package. I removed it because I realized that every java web project and its base abstract backing bean is too different from another java web project’s backing bean. None of the readers who sent me feedback could use my abstract backing bean because of their projects special demands. So this package is now gone within version 1.0.0.c.

How to use custom validation methods?

When determining a content constraint in your implementation of the ConstraintProvider return the following:


return new ContentConstraintData[] {
	new CustomContentConstraintData(0, new CustomValidationProvider(),
		"isEmailRegistered", Boolean.FALSE)};

The explaination is quiet easy:
By instantiating a new CustomContentConstraintData object and returning it in the contentConstraint-array, you instruct the validator to invoke your custom method “isEmailRegistered” on your given instance of “CustomValidationProvider”. The Boolean.FALSE is the value you would expect that method to return. The validation framework will parameterize your method with the value of the object which is going to be validated. In my example here, this will be the email address of type string. This is what my isEmailRegistered-method looks like:


public boolean isEmailRegistered(Object email) {
	//String strEmail = (String)email;
	//do some things... but just return false for this example
	return false;
}


The frameworks internal validator will compare the methods result with your given and expected value. If they don’t equal, the validation finishes with false (means not valid) and the messageKey you defined (here the Integer value 0). To translate this custom validationMessageKey, implement the “public ValidationMessage getCustomValidationMessageKey(Integer customContentConstraintId)”-method of the ValidationMessageKeyProvider-interface like this basic one:


public ValidationMessage getCustomValidationMessageKey(Integer customContentConstraintId)
		throws ValidationMessageKeyProviderException {
	return new ValidationMessage(String.valueOf(customContentConstraintId));
}

That’s it. I hope you find it useful. For further information about core components and customization of the framework, please refer to the example project until I publish a user- and developer guide here.

Leave a Reply


9 + = eighteen