Raible Designs

Validation Framework Consolidation

Looks like Jason Carreira has stepped up to the plate to try and consolidate the validation frameworks we have in Java. I'm sure it was a joint effort among many, but Jason's name is the only one I see on the JSR. I applaud this effort - it's definitely needed.

I've used Commons Validator, the XWork Validation Framework as well as Hibernate's Validator. While Commons and XWork work, the ability to annotate a class and validate it anywhere/anyhow is pretty cool. I reviewed an article a couple months ago that hooked Hibernate Validator into Spring MVC and Prototype for client-side validation. There's a lot of good stuff in this space - let's hope this JSR creates something even better. More than anything, let's hope it doesn't brush off client-side validation like JSF did.

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.

Posted in Java at Jul 11 2006, 02:05:37 PM MDT 18 Comments

Comments:

Hey, glad you think it's a good idea. I haven't gotten a lot of people involved yet, just some JSR spec leads I thought would be affected. Hopefully the JSR proposal will be accepted by the executive committee here in the next couple of weeks and we can build up a good expert group. I don't think you'll see a client-side validation framework in JavaScript come out of this... It's out of scope for what I'm looking to do, which is a generic JavaBean validation framework. What you probably WILL see is lots of tools building on top of this, since it seems like such a natural extension point for tooling. I expect you'll see at least one client-side library that builds on the spec, and probably more. The JSF component vendors, for example, should be able to easily build on validations defined for their backing beans and put in all of the nice JS validations you'd like... Likewise for Struts, etc.

Posted by Jason Carreira on July 11, 2006 at 02:44 PM MDT #

Sounds very interesting/important. I'm glad to hear the scope is intended to be something for end-user functionality to be built on top of; I expect that to be a much more flexible approach that will lead to better stuff than we have now; plus make it a lot easier for those who have chosen to/made the mistake of implementing their own framework to build upon.

Posted by Stephen Duncan Jr on July 11, 2006 at 02:55 PM MDT #

This is definitely a great proposal because we need a lot more consolidation and less fragmentation in the Java space. Rails is a clever example of increasing productivity. We need to learn from that.

Posted by Lars Fischer on July 11, 2006 at 03:39 PM MDT #

Hi Matt, thanks for pointing me to this, and Jason, great that you finally submitted the JSR. I signed up for the expert group. Take care, Geert

Posted by Geert Bevin on July 11, 2006 at 04:39 PM MDT #

At first I was hesitant about this announcement, only because of the trickling overlap between many of the recent JSRs, but Jason has the right scope and competancy for making this API addition work for everyone :-)

Posted by Jacob Hookom on July 11, 2006 at 07:42 PM MDT #

I don't see why this should be a JSR. Why not come up with a better validation framework and leave it at that. If people think its good, they'll use it. If it satisfies most users, people will stop writing new new frameworks. Spring isn't a JSR, neither are all its useful components like the JDBC helper classes, Spring remoting etc.

Posted by Sanjiv Jivan on July 11, 2006 at 09:49 PM MDT #

Sanjiv, it's because the door only swings one way. We've been through a decade of MVC and it's good to see these guys standardizing this space, not to detract from open source, but to increase adoption and agility for end developers with JSRs like this.

Posted by Jacob Hookom on July 11, 2006 at 10:51 PM MDT #

Jacob, the intent is certainly good but once an effort becomes a JSR, things move really slowly and agility of changes/enhancements is greatly reduced because now its a spec. As mentioned in a previous comment, client side javascript validation, which is an important part of validation in web apps (the primary driver of this spec), is already out of scope only because the guys owning the spec have chosen so. Once can only imagine how long its going to take to have an inclusion of this in the spec, let alone an actual implementation.

Posted by Sanjiv Jivan on July 12, 2006 at 04:35 AM MDT #

We've (Wicket) actually had contact about aligning with some colleagues about aligning the validation and conversion models. I think it was started by a couple of Struts people and if I remember correctly Jason was part of that discussion. Though we haven't heard of any follow ups. It might be a good idea to have such a thing, though the big *but* is that it easily gets to be a bloated beast without any concrete advantages. I mean, it sounds good to be able to reuse validators etc in other frameworks. But the problems start when you have to agree on how the reporting/ messaging works, how validations would be ordered, what the scopes are (field vs form vs business object), how to filter them (turn on and off) etc. It's something that is easy to write for a single framework - and easy to wrap if you need to reuse in another - but that's hard to write for all situations without making a mess of it.

As a side note, I don't really see the need to make this a JSR. Jason, what's the rationale behind that?

Commons Validator was an attempt to make a general validation framework. We considered using that for Wicket, but decided against it because it was too much bloat for our needs. But hey, maybe I'm just being too pessimistic. Jason, if you're really interested in making this a cross-framework thing, drop us a line.

Posted by Eelco Hillenius on July 12, 2006 at 07:18 AM MDT #

RE: Why make this a JSR

There are a lot of validation frameworks out there. Lots of libraries and frameworks touch on validation, and they seemingly all build their own validation. Most of the validation frameworks end up being pretty specific to the environment they're built for, whether it's a Swing UI or a web app, so it's hard to get re-use across projects, or even within one project from the UI through the back-end processing. And that's just the opensource libraries and people's applications... What about the other JSRs? JSF, JPA, Bean Binding, etc... All of them touch on validation. All of them either do or will end up implementing their own validation interfaces. They can't be written to commons-validation, it's not a spec. So then you're stuck with your web framework's validation framework API, your persistence tier's validation framework API, and probably your own applications validation API. How do you get reuse of validations across all tiers in the app?

I personally am able to use my validations front to back in both the web UI and batch processing, and we make use of that to have consistent validations throughout our app, but I'm pretty sure that's the exception, not the rule.

That's why we need a JSR for this. It should also make a nice platform for tool support, whether it's validation-aware Swing UI widgets or a JavaScript client-side validation library.

To Sanjiv's point, someone may convince me and the EG that a JavaScript library is in scope, but I doubt it. Read the JSR proposal. It's an extension to the JavaBeans contract. It's NOT driven by web app validation, but general JavaBean validation. There's been a lot of work going on defining meta-data about beans, and this is just another set of meta-data.

Plus, you can't say in one post that open source moves faster than specs then in the next post complain that we don't want to specify MORE... Especially something as quickly evolving and nebulous as JavaScript... I've never seen a JS validation library that gets everything right, and I'd hate to push out a "JSR-blessed" JS validation library that's not good enough for most people... Plus, what does a JS validation library mean for Swing apps?

Posted by Jason Carreira on July 12, 2006 at 08:13 AM MDT #

I read the proposal and it's about defining Java Bean validation related metadata, and not really a validation framework (which was the impression I got from Matt's post). A validation framework would be one that leverages such metadata to actually carry out the validation in different tiers. To me this spec is only addressing a part of the problem. A usable solution would be a framework that addresses the implementation of the propagation of this metadata to different tiers and the runtime execution aspect of the validation rules. For instance metadata propagation to a swing client and its executed. Similarly metadata propagation to the web tier which would need javascript to be aware of this metadata and be able to execute them. btw check out fValidate (http://www.phil-taylor.com/fvalidate/). It's a really powerful Javascript framework.

Posted by Sanjiv Jivan on July 12, 2006 at 09:52 AM MDT #

Sanjiv, I think what you are proposing is more than doable-- I think it's just a matter of standardizing how fields/methods/classes are annotated. Once the data is there, any framework could mine that data to coordinate JavaScript or UI-based validation either by invocation or translation (http://www.onjava.com/pub/a/onjava/2005/01/19/metadata_validation.html).

Posted by Jacob Hookom on July 12, 2006 at 10:16 AM MDT #

A standardized validation approach inside the Java language/SDK would be a huge added value to Java.

Not only for validating plain user-defined data, but certainly also in this age of dependency injection etc.

When validation rules can be defined inside/close-to the actual class, a class designer/developer could enforce the right checks to make sure an instance is ready for use, irrespective of type N IOC or whatever way of externalized instance initialization is used.

Externally defined validation rules (like the current typical XML-based stuff) could define application-specific extensions.

cheers

Erwin

Posted by erwin on July 13, 2006 at 02:40 AM MDT #

I agree that a JavaScript library is out of scope - but I think that meta data about script (not necessarily just JavaScript) validation should be considered.

Seems to me that there are different levels of meta data in a validation framework. Theres *global* type stuff such as configuring validation handlers for specific types - (e.g "this is my date handling routine") and then theres application specific meta data where you define the rules for that application (e.g. "validate that the credit card expiry date on my customer bean is a valid future date").

In the same way that the java (server side) needs to know how to get hold of the *global* routines and invoke them, providing the location of an equivalent script validation routine and something that knows how to render/generate the appropriate script to invoke it would be useful meta data for validation frameworks.

It also isn't necessarily a web/server side specific feature with the Scripting support coming in Mustang. I would say it would be deficient if the EG didn't at least give some thought to Script validation.

A while ago I developed this type of feature for Commons Validator - it was a first pass hack and hasn't been implemented, but worked pretty well:

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html
http://issues.apache.org/jira/browse/VALIDATOR-106

Posted by Niall on July 13, 2006 at 05:49 AM MDT #

1) I don't think that having Javascript validator is crucial. For Javascript validator to work browser has to support Javascript. If Javascript is on, than most modern browsers (including Opera for quite some time already) can generate asynchronous XMLHTTPRequest.

So, a mostly non-Ajax application has two options:

download a heavy chunk of Javascript validator code on initial page load and use it on submit. If error is found then we saved on request/response + some minimal server load. If error is not found then Javascript validator has been downloaded for nothing, it only has eaten bandwidth and time. For this reason I don't think that client Javascript is a real saver. And popup window with errors is just so 1998, it should modify DOM.
Use Ajax for validation. In this case every submit will cause a request to the server. On the plus side there is no Javascript to preload and if a user filled out a form correctly, no need to redisplay it. Also in this case there is only one Java validator codebase, so there is less to test and there is no need to sync Javascript validator with server-side validator. If applicaiton does not use Ajax at all or Javascript is not enabled then server validates input in the similar manner but a whole page is reloaded.

Another option is to use GWT, it can translate Java into Javascript. So if this JSR produces Java 1.4 compliant code, then there is a possibility to use GWT Java-to-Javascript compiler to produce Javacript validator code right from Java code instead of building Javascript validator routines manually.

2) Pulling metadata out of entity EJBs (anyone uses them?) or from database is important. But this relates not only to validation, but to automatic composition of backing bean / action form out of database schema. In would be nice if value objects/backing beans were created automatically using database schema, having proper type, size and constraints (validators, here you are).

Therefore I don't think that tackling metadata is up to this JSR. There should be another JSR for that. I think there is one proposed by Seam team.

Posted by Michael Jouravlev on July 14, 2006 at 11:31 AM MDT #

Ya... this JSR is surely gonna help in standardizing validation across all layers. no duplication of validation rules at each layers... m waiting for it....

Posted by Sudhir Nimavat on January 09, 2007 at 01:20 AM MST #

OVal looks very good: http://oval.sourceforge.net/ I would love to see something like this part of the Java standard because it could increase software quality. Sort of like assertions 2.0.

Posted by Anthony Whitford on January 28, 2007 at 10:11 AM MST #

just to know how to validate date in validation framework....how to write code in validation.xml

Posted by bhaskary on June 19, 2007 at 07:50 AM MDT #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

Validation Framework Consolidation