struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Affonso <glis...@greywether.com>
Subject Re: Validation Best Practices?
Date Mon, 29 Oct 2007 16:41:04 GMT
Tom Schneider wrote:
> This is essentially what we're doing as well, but it is far from an ideal
> situation.  The issue I've seen is that you can't easily use the validators
> from the xml in the validate() method.  Another disadvantage is that
> validation is in 2 different places.  Also, some of our validate() methods
> get pretty verbose--about 400 lines in one instance I looked at.  We'd also
> like to use the same validation code in the UI and in our business
> components.  Additionally, sometimes we need to call into the process layer
> to perform certain validation.  It also is hard to reuse validation using
> this technique.

Yes.

I did a lot of Webwork XML-based validation in our project (and ending 
up writing a good chunk of the current validation-related docs and I 
found out how it *really* worked) and, in the end, decided it has been 
pretty much a bad idea to do validation this way.

It's just not suited (IMO) for anything complex for the reason you note 
above and many others (no refactor support in most IDE's, very difficult 
to write and debug complex OGNL expressions, confusing and redundant 
validation syntax, etc)

Others seem to concur, during my exploration/documentation effort I 
asked essentially the same questions as you guys have (on the WebWork 
lists) and the general suggestion was to only use the XML-validation 
framework for simple stuff.

> * integrate Spring's valang into struts 2
> * replace the current xml with validation via ruby
> * replace the current xml with validation via Java, in a class separate from
> the action

Other options you might also consider are:

* integrate commons validation into Struts 2

Not suggesting this, just saying.

* integrate a "rules" framework like JBoss Drools

This, IMO, holds promise if you need an atom-bomb worth of validation 
capability.

> The last option [java-based validation] has the most promise.

That's one of our two top options: implement validation in Java classes 
corresponding to the "validated" class.

It'll either be that or something like Drools.  But Drools seems like 
complete overkill just as Struts 2 xml-based validation is underkill.

> Something along the lines of:
> FooAction and FooActionValidator which is automatically executed via an
> interceptor like the validate() method is now.  FooActionValidator would
> have helper methods to make the validation logic very concise.  I'd also
> like an interface like ValidationAware to capture the validation errors from
> lower levels of the application. (e.g. the process and dao layers)
> 
> So, anyone think I'm totally off base?

+1 on implementing validation in java.  Easily testable if you write 
your validation class well.

And yah, you could setup an interceptor and do a whole 
"auto-find-the-validator-class" sort of thing.  But why?  It's almost as 
easy to delegate, within the existing "validate" method and it's likely 
to be way more ide-refactor compatible than some sort of 
auto-class-loader thing.

I'm not quite sure what you mean by "lower levels of the application". 
Are you talking about doing something like validating an object returned 
from a database (presumably by something like hibernate)?

If that's the case, you might want to consider letting the objects known 
how to validate themselves with something like a "boolean isValid()" 
method.  And them maybe delegate within that to a validator class (and 
delegate *to* that from S2).

Then you could easily ask the object, at any point, if it was valid 
regardless of whether it was instantiated and populated from scratch, 
instantiated and populated by a DAO, instantiated and populated by 
Struts 2 after a form-post, etc.

If you really want to get jiggy with the "automatic" stuff  you could 
even do AOP interception on your setters/getters/constructors.  That way 
you couldn't even set a property on an object that was invalid (the AOP 
interceptor would throw an exception).  Although the AOP route makes it 
tougher to do validations that involve multiple-fields (you'd probably 
want to combine setter-AOP with something like an isValid() method).

Anyway, I'm still thinking through this myself (obviously) as I plan the 
re-write our our current xml-based validators.  The top choices at the 
moment are:

* Implement validation in a simple java class.  Probably do S2 
integration simply by delegating to that class in the S2 validate() method.

* Bite the bullet, climb the curve, and use Drools (Jboss Rules).

Curious to know what you settle on.

- Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message