Chris, There are a few non-struts/xwork-validation plugins that integrate with general purpose validation mechanisms. Off the top of my head, I remember this -
https://cwiki.apache.org/confluence/display/WW/OVal+Plugin But, I think there are two distinctly different things you are considering here. If you want to validate class instances that aren't linked in any way against struts/xwork libraries, then you should simply separate your validateable objects from your struts actions... For instance - public class YourAction extends ActionSupport { private YourValidateableBean propName ; // getters/setters/etc. public String execute() { return propName.execute(); } } I can understand your desire to remove the dependency of struts, making your actions reusable. But at the same time, without the helper methods that ActionSupport provides, implementing a mechanism for displaying validation failure error messages in the struts tags becomes extremely difficult. I will add, ActionSupport is linked only against classes provided by the JDK. And, that extending ActionSupport isn't a requirement, but not extending it means you will lose mostly the integration with the tags on the frontend. Even if you still don't want struts/xwork classes in your validation, i would suggest the OVal plugin, combined with a delegatory setup for executing your beans. -Wes On Wed, Apr 28, 2010 at 11:32 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rahul, > > On 4/27/2010 1:09 AM, Rahul Mohan wrote: >> I think the fundamental mechanism of S2 is the configurable interceptor >> stack where each interceptor applies itself to the current action based on >> the interfaces the action implements. You can still reuse this mechanism >> by defining your own interceptor stack with your own interfaces. Lets S2 ( >> or rather xwork ) take care of the wiring. Essentially, building your >> framework using the underlying configurable interceptor stack mechanism. >> Does that answer your question? > > Not really.... what I'm trying to do is build an action that does not > depend upon the S2/xwork APIs, but can still work with them. > > Specifically, I'd rather have: > > public class MyAction > extends (nothing) > implements (Nothing) > { > public void addFieldError(String field, String message) { ... }; > } > > rather than this: > > public class MyAction > extends ActionSupport > and/or > implements ValidationAware > { > // addError declared in ValidationAware > public void addFieldError(String field, String message) { ... }; > } > > I believe the ValidationInterceptor has code that looks something like this: > > if(action instanceof ValidationAware) > { > foreach field { > validate field > > if(error) > action.addFieldError(fieldName, errorMessage); > } > } > > I was wondering if there was any interest in an alternative > implementation that did something more like this: > > if(declaresValidationMethods(action.getClass()) > { > foreach field { > validate field > > if(error) > action.addFieldError(fieldName, errorMessage); > } > } > > I could certainly implement this myself, but I'm wondering if there is > wider interest in such an interceptor. > > Thanks, > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvYVScACgkQ9CaO5/Lv0PBmaQCfRGHa7iD3rOUkukq9mRbiNW/F > d7MAmwfYI3P0iUhD3lnZs0U7jv+qHj5h > =Y6iv > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
