Joe
deepaksawdekar wrote:
Hi, What about the setter methods of the action form. They may throw some IllegalArgumentException when you are trying to set some of wrong arguments in the form. How will you take care it.
Deepak.
-----Original Message----- From: Joe @ Team345 [mailto:[EMAIL PROTECTED] Sent: Saturday, August 30, 2003 7:00 PM To: Struts Users Mailing List Subject: Re: Repost: Validations in Action Form
No, IMO you should not do what you outline. Rather, use the "Struts Validator Framework" to do validation. It took me a little bit to get the first "required" validation to work right. After that though you get used to it very fast. It is simple, extensible and your validations are not in code, but in XML files. I did find one limitation though. EVERY value I use on a form I represent as a String. Then I have the Action class validate. If validation proceeds then I do any necessary type conversion in the ValueObject.
So if I had a date field (call it startDate) in the form I would have accessor methods:
public String getStartDate()....
public void setStartDate(String date)....
and it my value object I would have accessors for any "derived" types I might need:
public java.util.Date getStartDateAsUtilDate()....
public java.sql.Date getStartDateAsSQLDate()...
this way you know you can create the date objects from the string when you create your value objects because you have passed validation..
hth
And it my Value
Adam Hardy wrote:
Hi Siriam,
there are no struts framework rules. There is the MVC framework which you should try to adhere to and not violate, which is why you are using struts, right?
There are areas in struts where the adherence to MVC design, or even OO design, is not 'optimal', caused by the interfaces between model and view, or view and control, or control and model.
It's the same with OO - there are people who say struts should incorporate action classes and form classes so that functionality is encapsulated with its related data.
Somewhere there has to be a compromise for the sake of productivity.
I've done what you outlined below. It works great having the validation checks in the value objects, especially for using nested beans. While it enhances OO design, it does decrease MVC seperation because you now have classes in your model (that's where you send the value objects I presume) where you can call View-layer validation. Not that you would, but it would niggle the purists.
Adam
On 08/29/2003 01:18 PM sriram wrote:
Can some please validate this?
My application uses Struts Action Form.
I am also using Value Objects.
I am not doing validations using validations.xml and validator-rules.xml. I'm performing simple validations on server side as follows:
Can some one please check the below code and tell me if what I am doing is correct?
In Action Form "validate" method, the code as follows:
===== code in validate method of ActionForm ==========
ActionErrors errs = new ActionErrors(); MyValues val = new MyValues();
try {
val.setInputField(inputField_);
} catch (IllegalArgumentException ex) {
errs.add(FLD_INPUT_FIELD,new ActionError("myviewform.error_input_field",ex.getMessage()));
}
===== code in Value Object - MyValues =============
public void setInputField(String val) {
if (val==null || val.length()==0) throw new IllegalArgumentException("Illegal null parameter passed to setInputField");
if (val!=null && val.length()>100) // max length of this field is 100
throw new IllegalArgumentException("Illegal parameter value too long passed to setInputField,value="+val);
inputField_=val;
}// end of setInputField
============================================================
With the above code, can I say that the validations are written in "validate" method of ActionForm? Someone mentioned that since I'm performing actual validations in MyValues, the validations are not being done in ActionForm, and so it does not follow Struts Framework rules. Is this true? Please clarify.
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
