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>