commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Rood <wes9...@myfastmail.com>
Subject BeanUtils / ConvertUtils and custom converters
Date Wed, 12 Nov 2003 22:30:54 GMT
I have written a few custom org.apache.commons.beanutils.Converter 
implementations.

For example, I want to convert my particular String date representation 
to a java.util.Date object and vice versa using BeanUtils.copyProperties()

So for when the destination property is a Date, I have a custom Date 
converter with a convert method that checks to see if the incoming 
source attribute is a String, and if so, converts to a Date, otherwise 
it passes the object through unchanged.

Then I had to write a similiar converter for when the destination 
property is a String, which checks to see if the incoming source 
attribute is a Date, and if so, converts to the String form, otherwise 
it was passing the object through unchanged.

I came to understand through some usage of these converters, that when I 
registered my custom converters, I had actually replaced the default 
converters for these 2 types.  I started having problems when the 
Numeric datatypes were being converted to strings, because I was passing 
the object through unchanged if the incoming type was not a Date.

So I looked at the default String converter in the BeanUtils source, and 
saw that it was simply doing a toString() on the object, so I changed to 
return object.toString() instead of previously returning just the object.

This solved the problem, but it leads me to a question (finally :) )

My initial thought for a solution was not to look at the default 
implementation and repeat the same operation, but instead to subclass 
the default StringConverter and override the convert method.  I would 
then code my date conversion if the incoming object was a Date, and if 
not, just call super.convert() on the object, thus picking up the 
default behavior.

But I found that the 
org.apache.commons.beanutils.converters.StringConverter is final, so I 
could not do that!

Any thoughts?

My 2 ideas are:
1. Allow the default Converters to be overridden
or
2. Somehow have the custom converters applied first, then have the 
default converters automatically applied after the custom ones.

I prefer 2, but don't know of the implications.

Thanks!
Wes


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message