JSR 303: Time to Standardize Validation
According to Jason, there is a need for this standard because:
Validation is done now in an ad-hoc fashion across all of the application tiers, and usually ends up being duplicated. There are some frameworks, like commons-validator and the XWork validation framework, which look to provide a reusable framework for validation, but very few organizations make full use of validation across the view and model tiers, and there's a lot of duplication and wasted effort in this area. There's also a need to plug in validation in several other JSR's, for example JSF and JPA. In order for these JSRs to not duplicate validation efforts, there needs to be a validation JSR for them to reuse since they can't be based on using an opensource library.
On the types of validation that will be specified in the metamodel:
I think more than anything it's important to define the framework for applying validations and defining validators. The common validations will be included, such as "required", date and number ranges, etc. Depending on how the Expression Language JSR is progressing, we may be able to have an EL validator that gives a more ad-hoc validation mechanism. I'm also hoping to keep the ability to pass validation along to a sub-property to apply that objects validations, like we do with the XWork validation framework with the Visitor field validator.On how how the validation facility could be used consistently across different tiers:
The Visitor field validator really enables the modular reuse of domain model validations across different validation contexts.
I think the most important thing, though, will be to define the ability to build your own custom validations using both annotations and XML meta-data. Obviously the limitations of annotations provide interesting challenges here, but we've got some time to work that out.
Well, I'll have to use the XWork validation framework as the example. I built the XWork validation framework while we were facing issues of implementing consistent validations across both the view tier and the domain model for batch processing at Notiva. At my current employer, ePlus, we apply our validations to our Hibernate mapped domain model classes and use the validations in our web UI and also in our batch import processing. Mostly these validations are the same, but there's also some validations which are UI specific, for example entering the password twice when adding a new user. The concept of validation context specific validations in the XWork validation framework allow us to have a common set of validations which are always applied, and also have additional validations which are specific to whether the validation is done in a web UI context or a batch processing context. It's all a common set of validation meta-data, but the context-sensitive ability lets us customize the validations to the use case.
Jay Bose and Matt Raible also blogged approval of the initiative, with Matt adding "In an ideal world, the RIFE, Spring MVC, Stripes, Struts, Tapestry and Wicket developers will all participate and allow JSR-303's result to be used as their framework's validation engine. I think it's a given that this will be usable with JSF."
Not just for webapp frameworks
When I need to do custom validations, I frequently find that my logic is too complex to be expressed in ExpressionValidator. I hope you will add support for a validator that allows you to delegate to a custom boolean method within the class.
@CustomValidator(message = "Complex validation failed", shortCircuit = true, method = "complexValidator" )
struts 1 and jsr 303 integration with sbva
to allow easy integration of jsr-303 with struts 1. If you try it
please let me know what you think.
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015