These don't necessarily have to exist in the same form, but I don't see why they shouldn't be supported if they were. I disagree that the ConvertUtils should not be responsible for conversions of this sort.
My point is that the ConvertUtils libraries are built around a specific metaphor, as embodied in the interface. Given a string (and only a string), use a standard format template to convert that string into a specific type.
As Robert Burrell Donkin noted in this thread on commons-dev, if your solution involves changing the "Converter" interface, it's going to be very hard to sell, as who knows how many people have implemented Converter and would have to go changing those implementations.
Perhaps if you could pitch it as a wrapping layer around ConvertUtils -- an "AdvancedConvertUtilsBean" class which could register converters of some sub-interface which extends Converter.
Alternatively, take advantage of the fact that it's now possible to deal with conversion using a ConvertUtilsBean (which hadn't been the model of the original Struts form population) and devise a way to build a new ConvertUtilsBean as necessary each time processPopulateForm is called.
This won't be possible if you want one ConvertUtilsBean to convert Strings in different formats to the same Date type -- in that case you'd either need to go back to the AdvancedConvertUtilsBean approach, or declare your form properties to be of various subtypes of java.util.Date, each of which might have a different Converter registered. (com.foo.Time extends java.util.Date, registered with "HH:mm"; com.foo.Month extends java.util.Date, registered with a converter "MMMM", etc...)
The ConvertUtilsBean seems somewhat more promising to me, but coming up with a clean design that is not a burden on people who don't need it still seems like more work than declaring your form properties to be strings and dealing with the conversion in business objects...
Joe
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
