NYIMI Jose (BMB) wrote:
As it has been pointed out a few times on this list, there are different types of validation. The validation in struts is intended for user input validation, not necessarily business logic validation. Input validation being that a number is input instead of a alphanumeric string, or other such 'simple' validation. I agree that business logic validation should happen in the domain objects. Things like cross property validation, cross object validation, verifying a user name/password, etc. etc.True data binding is generally inflexible and troublesome. Having come from the VB world many years ago, and its data binding way of doing things, I can say that I can't stand it. Having a middle ground creates more opportunities and power than not having it. I know some who still do data binding in swing apps, and they end up doing lots of hacks to perform things like validation, both simple and complex, and other 'process' type of actions. All of this is easy to do with the way Struts handles things. Taking the data out of a DynaForm once I'm done doing simple validation and maybe some pre-processing, then doing a simpleRod Johnson, recommanded the following :
"Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types".
He continued by :
"Validation in the web tier has the severe disadvantage of tying validation logic(which may be business logic) to the Servlet API and perhaps also to a web application framework.
Unfortunately, Struts tends to push validation in the direction of the web tier, as validation must occur on Struts ActionForm objects, which depend on the Servlet API, and hence *cannot* not be passed into an EJB container and should not be passed to any business object. For example, validation is often accomplished by overrinding the org.apache.struts.action.ActionForm validate method.
I consider this (and the fact that ActionForm objects must extends a Struts superclass dependent on the Servlet API) to be a major design flaw.
copyProperties call to take the string version of the data and populate a 'real' domain object is to easy for me want to give up.
With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. Jos�.
The same could be said for db validation. The database is good at validating referential integrity and things like that. Domain objects are good at cross property/object validation and other business rules that aren't necessarily db or input specific.
As we tell our clients, "validate where it makes sense". Sometimes that means in all three places, sometimes not.
- Robert
- Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**** DISCLAIMER ****
"This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer".
Thank you for your cooperation.
For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
