You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Sean Kleinjung <sk...@gmail.com> on 2007/10/24 18:20:49 UTC
Validation Best Practices?
Hey,
I have a question concerning where validation should be performed, and
what people feel best practices are. Specifically, I have a number of
business objects that validate parameters supplied to their setters
for correctness, and throw IllegalArgumentExceptions if something is
invalid. For example, in a hypothetical Person class I would have:
...
public void setAge(int age) {
if (age < 0) throw new MyInvalidValueException("some i18n-ed
error msg");
this.age = age;
}
....
This is done so that if there is a failure to properly validate at
some other layer of the application, it will fail-fast and allow the
problem to be debugged more easily. (It also gives confidence that all
references to a business object do not contain invalid data.)
Now, we are using Struts2 and intend to use the provided annotations
for validation. The problem is, if I create the app so that HTTP
parameters are set directly on the business objects (by using a 'name'
value of "person.name" for a form field, for example), these
exceptions will prevent the value from being set, so validation is
never performed (and no errors are set on the action).
The way I see it, I have three options:
1) Remove all validity checks from the business objects, and rely on
Struts to validate incoming data, and the DAO layer to validate them
before inserting. This would probably be the simplest option, but I
wanted to get peoples thoughts on it first. Are argument checks like
the ones above a good idea? Or is it better to have these type of
objects be dumb-data transfer objects that will carry any value they
are given?
2) Duplicate all properties of the business objects on the struts
actions, where they can be validated using the validation annotations.
The action methods must then copy the values into the business objects
as needed. This would allow the business objects to remain unchanged,
but has a lot of duplication and maintenance overhead if fields are
added/removed/changed. (It basically reminds me of the nightmare of
Struts1 form beans :p )
3) Extend the ParametersInterceptor and/or validation interceptor to
do some kind of "magic" involving catching the argument exceptions,
setting appropriate errors on the action, and preserving the invalid
values so that they can be redisplayed on the form. This option is
definitely the most work (and I haven't looked at the Struts source
closely enough to know exactly how much is involved, and if its even
possibly to do in an elegant fashion).
So in addition to commenting on the above specific situation, the
general question is this: should business objects be self-validating,
and how should they handle validation errors?
Thanks in advance for any input,
Sean Kleinjung
AV Support, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Tom Schneider <sc...@gmail.com>.
That looks like an interesting project. There are a lot of things that I
like about what they are doing. There are a lot of things that could be
handle that way. My fear with making everything a seperate Rule class is
that some things cannot be encoded as a simple rule. Somevalidation needs
too much information and requires too much external information. This
framework would be great as something to build on top of though. Thanks for
pointing it out.
Tom
Joachim Ansorg-3 wrote:
>
> Tom,
> I've read this thread with great interest.
>
> Currently I'm thinking about the validation problem as well. I looked at
> springmodule's Bean validation framework.
> (https://springmodules.dev.java.net/docs/reference/0.8/html/validation.html#beanValidator).
> Looks quite interesting to me.
> Does somebody have any experience using it together with Struts 2?
>
> Do you have any experience now using validators in seperate classes?
> If yes, which validation framework did you choose and what is you
> opinion now after using this approach?
>
> Thanks for any hints,
> Joachim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13606501
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Joachim Ansorg <ja...@ksi.gr>.
Tom,
I've read this thread with great interest.
Currently I'm thinking about the validation problem as well. I looked at
springmodule's Bean validation framework.
(https://springmodules.dev.java.net/docs/reference/0.8/html/validation.html#beanValidator).
Looks quite interesting to me.
Does somebody have any experience using it together with Struts 2?
Do you have any experience now using validators in seperate classes?
If yes, which validation framework did you choose and what is you
opinion now after using this approach?
Thanks for any hints,
Joachim
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Tom Schneider <sc...@gmail.com>.
Just wanted to point out: http://jcp.org/en/jsr/detail?id=303 which is
relevant to our discussion. No activity on this JSR since July of '06. I'm
not convinced that annotations really solve the problem. I think for
anything more than simple type checking you need a true programming language
to define the validation rules.
--
View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13477655
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Tom Schneider <sc...@gmail.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Gary Affonso <gl...@greywether.com>.
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
Re: Validation Best Practices?
Posted by Tom Schneider <sc...@gmail.com>.
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.
All these issues indicate that an alternative to the current validation is
needed. This is especially true for bigger apps that have multiple layers
and very complex validation at multiple levels. Don and I were discussing
this yesterday on #struts and here are some of the options we came up with:
* 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
The last option has the most promise. 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? I'm not ready to implement anything
yet, however, I think this might solve some of the issues that we've been
having with our validation.
Tom
Igor Vlasov wrote:
>
> I use validate() method from ActionSupport for complex bussines
> validation.(it works in WorkFlowInterceptor).
>
> Sometime, for trivial fields, i can use Struts ValidationFramework.(it
> works after ParameterInterceptor)
>
>
--
View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13453669
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Validation Best Practices?
Posted by Igor Vlasov <vi...@mail.ru>.
I use validate() method from ActionSupport for complex bussines
validation.(it works in WorkFlowInterceptor).
Sometime, for trivial fields, i can use Struts ValidationFramework.(it
works after ParameterInterceptor)
Sean Kleinjung-2 wrote:
>
> Hey,
>
> I have a question concerning where validation should be performed, and
> what people feel best practices are. Specifically, I have a number of
> business objects that validate parameters supplied to their setters
> for correctness, and throw IllegalArgumentExceptions if something is
> invalid. For example, in a hypothetical Person class I would have:
>
> ...
> public void setAge(int age) {
> if (age < 0) throw new MyInvalidValueException("some i18n-ed
> error msg");
> this.age = age;
> }
> ....
>
> This is done so that if there is a failure to properly validate at
> some other layer of the application, it will fail-fast and allow the
> problem to be debugged more easily. (It also gives confidence that all
> references to a business object do not contain invalid data.)
>
> Now, we are using Struts2 and intend to use the provided annotations
> for validation. The problem is, if I create the app so that HTTP
> parameters are set directly on the business objects (by using a 'name'
> value of "person.name" for a form field, for example), these
> exceptions will prevent the value from being set, so validation is
> never performed (and no errors are set on the action).
>
> The way I see it, I have three options:
>
> 1) Remove all validity checks from the business objects, and rely on
> Struts to validate incoming data, and the DAO layer to validate them
> before inserting. This would probably be the simplest option, but I
> wanted to get peoples thoughts on it first. Are argument checks like
> the ones above a good idea? Or is it better to have these type of
> objects be dumb-data transfer objects that will carry any value they
> are given?
>
> 2) Duplicate all properties of the business objects on the struts
> actions, where they can be validated using the validation annotations.
> The action methods must then copy the values into the business objects
> as needed. This would allow the business objects to remain unchanged,
> but has a lot of duplication and maintenance overhead if fields are
> added/removed/changed. (It basically reminds me of the nightmare of
> Struts1 form beans :p )
>
> 3) Extend the ParametersInterceptor and/or validation interceptor to
> do some kind of "magic" involving catching the argument exceptions,
> setting appropriate errors on the action, and preserving the invalid
> values so that they can be redisplayed on the form. This option is
> definitely the most work (and I haven't looked at the Struts source
> closely enough to know exactly how much is involved, and if its even
> possibly to do in an elegant fashion).
>
> So in addition to commenting on the above specific situation, the
> general question is this: should business objects be self-validating,
> and how should they handle validation errors?
>
> Thanks in advance for any input,
> Sean Kleinjung
> AV Support, Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13423610
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org