I hit the same problem. I don't like having two fields (string and type specific) as you have to sync. them and it bloats your objects out. I don't like the idea of having two suites of objects, it's just more work. I don't like not using the validator either. I made some minor modifications to beanutils/convertutils to allow for the passing through of the property name in question. You also need to get access to the ServletRequest object in your custom converter (I did this using a filter which stores the requests in a thread local object, which you may find distasteful). I don't want to loose any erroneous input the user entered, so my custom converter writes the input into the http request (just using the full a.b.c notation is a key) and this is then put back into the jsp using a slightly modified TextTag. You have access to the request in your converter, so you can build any validation errors there.
Regards, Graham. -----Original Message----- From: Edgar P Dollin [mailto:[EMAIL PROTECTED] Sent: 17 September 2003 12:33 To: Struts Developers List Subject: RE: Conceptual question about populating/validating values If I were you I would use strings in my form beans (or at least methods or parallel field which accept strings as arguments) and look into third party stuff, i.e. Matt Kruse's date handling javascript. Additionally, I would bypass the validator and validate in my action (that way you would have the text the user entered). It is easy enough to emulate the validator flow of control (just read the mapping and get the 'input' value and forward to it). Edgar > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 6:23 AM > To: [EMAIL PROTECTED] > Subject: Conceptual question about populating/validating values > > > 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] > --------------------------------------------------------------------- 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]
