The other leading Java frameworks are WebWork, Maverick, JPublish, and Barracuda, if you care to have a look. After choosing Java itself, selecting an application framework and persistence layer are the most important decisions you will make. So, it's worth shopping around.
For harvesting form values, I've been playing with FormProc recently. It has a different approach than the Validator, in that it doesn't validate JavaBeans, it validated a list of input entries against a collection of field elements that comprise the form. Once the input for a field is validated, then it is converted and transferred to a target object (an arbitrary JavaBean or Map implementation).
One thing to note is that FormProc doesn't do a wholesale transfer. If a parameter does not correspond to a field element, it is not harvested. So, you don't have to worry about inappropriate properties being populated by a hostile client. Also, the target property (or entry) is only populated *after* it has been validated, so bad data is never tendered to good objects =:0)
Meanwhile, the original input is maintained on a separate List. So, when you go back to the page, you can redisplay the original (buffered) input, whether it was valid or not. (Well, I had to submit a patch for that one, to give the list a public accessor.)
I'm working on a FormProc extension for Maverick now and may try one for Struts next (by hooking into the reset method). This would let you define your form without subclassing a base ActionForm, much like the DynaActionForm.
-Ted.
[EMAIL PROTECTED] wrote:
Hi there,
I have a conceptual question about the population process for properties inside Struts.
First of all a description:
I have a JSP which includes a text input field like this:
<html:text name="myForm" property="currentPerson.birthDate"/>
"currentPerson" is a Person-Object which has a birthDate-Attribute of type
java.util.Date (!).
This object is part of the myForm-Bean.
I know about the alternative to have string values in my FormBean and set the property of my object "by hand", but I don't like this !!
The Request-Processing now does the following:
1. RequestProcessor.processPopulate(...)
2. RequestUtils.populate(...request)
3. BeanUtils.populate(bean, properties)
...
4. BeanUtils.setProperty(...)
5. ConvertUtils.convert(...)
6. PropertyUtils.setProperty(...)
6. RequestProcessor.processValidate(...)
..
In my example the string representing a date is converted into a Date-Object in step 5 (ConvertUtils.convert()) I could use the sessions locale here for LOCALE-specific conversions and set a default value in case the conversion failes. I know about this !
Lets asume the following:
-> A user enters an invalid date -> conversion failes and the default value will be set as birthDate
-> the user gets the page back including an error message about an invalid
date
-> the date input field holds the default date now
BUT: What I would like the user to see is it's original text, not the default value or anything else.
ANY IDEA, how to do this ? (Without having string variables to store the form-values !) Since I also would also like to specify a regexp-mask in the validation.xml it looks to me, that the processValidate() is a bit too late.
Thanks in advance, Dirk
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
