You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2002/12/10 18:58:20 UTC

DO NOT REPLY [Bug 14170] - ConvertUtils.convert(Object) doesn't use registered convertor

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 rdonkin@apache.org  2002-12-10 17:58 -------
bit more to this than first met my eye...

the basic idea is that ConvertUtils would perform conversions when getting properties as 
well as setting them. this would mean that the getXXXProperty methods in the BeanUtils 
class would allow custom conversions rather than the simple toString() call used at the 
moment.

the existing convertor interface can be reused

public object convert(java.lang.class type, java.lang.Object value)

by passing in type String.class.

whether existing convertor classes could be used for this all depends on how they were 
written. it seems likely that many won't work very well - and some, not at all. we can 
convert the ones in beanutils but not those created by users.

at the moment, ConvertUtils only needs one register for convertors since it only converts 
property setters. if ConvertUtils is going to convert getters as well, the question arises 
whether two separate registers are needed, one for setters and one for getters.

one register should be easier to use and should make a little more sense from a user 
perspective. without losing too much flexibility (so long as the convertors are well 
written).

having only one register might cause problems with existing code. if the registered 
convertors don't behaviour reasonably when called to convert objects to string, then the 
existing code would break.

anyone else have any thoughts...?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>