DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321 Automatic invalid format handling for form bean ------- Additional Comments From [EMAIL PROTECTED] 2004-02-29 13:57 ------- I think the underlying problem is that we still lack a slick package that can handle data validation, tranformation, and conversion from a single configuration. Instead of trying to wire arbitrary JavaBeans up to an ActionForm, we should be able to populate a typed JavaBean from a package that takes a Map of Strings as input AND: return a Map of FORMATTED strings from a typed JavaBean. Bidirectional conversions and transformations being essential for roundtripping input to the persistence layer and back again. By transformation I mean taking a String like "1234567890" and rendering it as "(123) 456-7890", or taking a Date or Double and rendering the data in whatever style. One package that comes quite close in this regard is FormProc at SourceForge (formproc.sf.net). It's underdocumented, and we need to make the conversions bidirectional, but, IMHO, it's moving in the right direction. The essential idea is that same configuration that tells us incoming dates (or whatever) are formatted in a certain way would also tell us that outgoing entries are formatted the same way. Ditto for currencies, and telephone numbers, and so forth. Given such a beast, we could then populate and debrief business objects with one simple call. We could even allow an arbitrary object to be (optionally) associated with an ActionMapping and autopopulated if validate passes. This would not change the nature of ActionForms in anyway, or require any additional configurations information over what is already provided, but simply leverage what we already know, to do what most everyone needs to do. But what's still needed is the ability to execute bidirectional conversions/transformations with the Validator, or something like it, then the rest falls into place. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
