I think drools would be way overkill for simple validation. Not only would there be a high learning curve, I don't think it would handle the most involved cases. I really think we need to do Java by default.
The reason I included a way to autofind the validation class is to mimic how the existing xml validation automatically works. I'm OK with doing delegation to another validator in the validate() method of the action, I just thought it might be nice to have convention over explicit delegation, but I'm open to other ideas. I would definitely use another validation API under the hood. My idea would be to have a standard set of convenience validation methods in the super class that defers to either commons validation or Spring's validation support. I'd like the validation code to be as concise as possible, an API similar to Spring's valang might work--except in java code instead of a custom language. If others would find this kind of thing useful, I think it would be useful to create a googlecode project to begin a proof of concept. Work through what the API would look like because I think it would be a great alternative to the validation framework that's in place now. (And as I stated before, I would love to use this both at the UI level and at the business logic/component level) Tom Gary Affonso wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13473039 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
