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=14170>. 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=14170 ConvertUtils.convert(Object) doesn't use registered convertor ------- Additional Comments From [EMAIL PROTECTED] 2002-12-16 09:05 ------- Hello Brian, hello Robert, we also came across that problem when trying to convert Date/Calendar values appropriately. IMHO the existing Converter interface should *not* be used for the purpose of *un*converting Strings for the following reasons. If only one Converter had to be registered, existing Converters may not support converting to Strings and thus fail to work. If two Converters had to be registered, there would be multiple Converters for the type "String". But how does (or should) ConvertUtils handle multiple Convertors for one target type? Call them one after another until one does not fail? Also, I think it is much better to keep the code converting from some type to String and from a String back to the type together in one class. My proposal would be to create a sub-interface "BidirectionalConvertor" (or so) with an additional method signature String unconvert(Object value); (or "toString", if you want). ConvertUtils must then check whether the registered Convertor for the type *also* supports the BidirectionalConvertor interface and if so, call its unconvert method. Otherwise, the fall-back is to call the toString method (or rather: String.valueOf?) as before. This would mean that existing Convertors would work as before. The standard Convertors could be rewritten to support unconverting. What do you think? Greetings, -Frank- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
