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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-21 19:54 ---
I've implemented a partial solution to this problem, which should allow
applications to do custom Object->String conversions without impacting the rest
of how beanutils conversions work.  It is available in the 20021222 nightly
build of commons-beanutils.

The basic idea is that the "ConvertUtils.convert(Object value)" method now uses
the registered Converter for java.util.String.  The default implementation of
this Converter uses toString() -- preserving backwards compatibility -- but you
can register something that is smarter for your own needs.  The drawback is that
this single Object->String converter needs to be smart enough to handle *all* of
these conversions, not just your custom ones.

A longer term solution would be to move towards bidirectional converters of some
sort.  But let's see if this change satisfies the immediate needs.  Could you
test it, please?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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:   
For additional commands, e-mail: 

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-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:   
For additional commands, e-mail: 

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-30 17:12 ---
i'll take a look at creating a fix for this

--
To unsubscribe, e-mail:   
For additional commands, e-mail: