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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
