Struts 1.2.9 Scenario: There is a form which is associated with 3 actions, A, B, and C.
A and B need the same validation rule while C is different. I have no problems to get them work, if I duplicate the valiation scripts in validation.xml, for A and B. (The trick is to use getPath() rather than the getAttribute() in the Form bean).
Question: how can I avoid to the duplications for A and B? Is this possible in Struts?
(The trick is to use getPath() rather than the getAttribute() in the Form bean).
I'm not quite sure what you're referring to here, but the recommended way to validate by action is to have your form bean extend ValidatorActionForm rather than ValidatorForm and then supply the action path as the name in the validator.xml file.
Since you're validating by action rather than by form, I don't know a way to avoid the duplication. Since A and B are separate actions, you must provide separate validation rules for them, even if those rules are the same. [ August 31, 2006: Message edited by: Merrill Higginson ]
Thanks for the reply. I've figured out an easier way - no need to duplicate.
a) You don't have to override ValidatorActionForm. What I did is to override ValidatorForm and (!!) override the following method
b)The name for the <form /> in validation.xml could be any string as long as your getValidationKey() understands it.
[ August 31, 2006: Message edited by: Wu Kong ] [ August 31, 2006: Message edited by: Wu Kong ]
Joined: Feb 15, 2005
Your solution is ingenious and does solve the problem of duplicate validation declaration.
I'm a little uneasy about it, though, from an architectural standpoint. Struts Validation framework is based on the principle of "declarative validation". The way it's set up, one can look at the the validation xml files and the struts-config.xml file and know everything about what is going on with validation.
Your solution corrupts this principle just a little. When a struts-savvy user looks at the validation.xml file, he/she is looking for either a form name or an action path as the validation form name. You've now made this name an arbitrarily set parameter in the action mapping. This parameter is not normally used by validation, and it's role in your validation logic is not intuitively obvious to a new observer trying to understand the application. In addition to this, one has to know what's in the code in your overridden method to understand which validation will be used
While I'm sure it works great, from my point of view, it reduces the maintainability of the application. If you go with this solution, I'd suggest putting some comments in your validation.xml file that provide a thorough explanation of what's happening with this validation.
Joined: Jun 12, 2006
Thanks for your comments and I fully understand your concerns regarding the maintainability.
The challenge is that my Form has approx. 40 fields and it's hard for me to justify if I take the approach of duplicating the validation logic in two parts which poses a maintainability issue as well. I'll take your suggestion and put commnets in the validation.xml indicating this is something ususual.
I agree that support for inheritance and reuse is a drawback of the validation framework. For example, many of my forms contain other reusable object. For example I have a LocationInfo class that contains various coordinate fields (degrees latitude, minutes latitude, seconds latitude, etc...). If 20 forms contain this object I have to cut and paste the validation twenty times. Sometimes it seems easier and cleaner to just use some utility methods and implement the validation in the form object. That I could just call a validate method on my object, or use a common validateLocation method.
WK: thanks for the tip...I can't say I have ever heard of the getValidationKey method.