often this is a hard call for library code.
i don't really understand the problem in depth (maybe someone could enlighten me perhaps by providing some examples) but i'd be more inclined to think about extensions along the lines proposed recently by Eric Pabst than by changing the basic interfaces. (more about this in another email.)
i would be interested to hear what other people think about this.
- robert
On Tuesday, July 1, 2003, at 06:56 PM, Jon Wilmoth wrote:
I'm cross posting due to the interproject dependencies. It has been requested that the Struts framework provide more robust support for submitting/displaying UI fields (dates as a prime example) that have string-->object conversion requirements not currently covered by the BeanUtils project leveraged by Struts. I suggested that the exiting Converter interface be expanded to accept parameters (Map of configurations?) to allow custom converters to be more flexible in their implementations. However, the Struts API accesses the ConvertUtils through the BeanUtils.populate method and that would also require modification. Because of the multiplicity of fields handled by the populate method, perhaps a new datastructure (PropertyChangeDefinition?) is appropriate for communicating the new value, the target datatype, a converter, and perhaps some conversion parameters?
--- Jon Wilmoth <[EMAIL PROTECTED]> wrote:Date: Tue, 1 Jul 2003 10:45:44 -0700 (PDT) From: Jon Wilmoth <[EMAIL PROTECTED]> Subject: [BeanUtils & Struts]RE: Support for Date datatypes!!! To: Struts Developers List <[EMAIL PROTECTED]>
I did investigate registering "custom" converters. Unfortunately, anything that would support non-hard-coded conversion patterns will require either a mixed paradygm usage (i.e passing a complex object that contains the value to convert and all convertion configuration instead of simply the value to be converted) of the existing Converter.convert interface or additional parameters. Since I think everyone can agree that the first option is confusing and should be avoided when possible the remaining option is to modify/extend the interface. I agree this should be communicated within the BeanUtils developer mailing list and will cross post this in hopes of getting further creative approaches to the problem. Because Struts will be responsible for providing the means to invoke the conversion (and much more) I do feel it is appropriate for this list to continue to discuss the Struts/BeanUtil interaction necessary for this functionality.
--- Wendy Smoak <[EMAIL PROTECTED]> wrote:further
[Not a developer, but I've been following this because I ran into the date problem early on.] I use BeanUtils.copyProperties to move things back and forth from ActionForms (all String properties) and my DTO's, as shown in the struts-example webapp. At some point I thought needed a Java "Date" object in the DTO (that requirement went away withregisteringdevelopment). And the existing SQL formatted Date converter wasn't going to work, my database doesn't understand that format.
What was suggested to me is writing andmy own Converter with BeanUtils. I don't think I went through with it, but that made perfect sense to me. IMO, Struts shouldn't get involved with Date conversions, that's already the job of Commons BeanUtils.
-- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
--------------------------------------------------------------------- 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]
