I am using BeanUtils.copyProperties(Object dest, Object orig) to copy from
my "view" beans to my dto beans, and vica versa. I find that I need to apply
slightly different rules based on which direction I am going. I would like to
add the idea of a "ConverterSet" to beanutils, and plan on passing up the
changes, if anyone is interested.
Here are the changes I am looking at:
Add a new ConverterSet class, which will contain a hashmap of Converter
objects, and a name, as well as lookup and set methods for Converters.
Add a new method in BeanUtils with the signature copyProperties(Object dest,
Object orig, ConverterSet converterSet). The current copyProperties(Object
dest, Object orig) will chain to this new method, using a default ConverterSet.
There will be many other methods in BeanUtils and ConvertUtils which will also
have to undergo the same transition- i.e. copyProperty(Object bean, String
name, Object value), etc..
In ConvertUtils, I will add a "Converter lookup(Class clazz, ConverterSet
converterSet)" method, along with register(...), etc. Basically everything that
currently does a lookup on the converters variable inside of ConvertUtils will
be changed to allow the specification of a ConverterSet, and the default will
be used if none is specified.
I will add a utility method on ConvertUtils to retrieve a given ConverterSet:
public static ConverterSet getConverterSet(String setName)
That should all be pretty straight forward and will maintain backwards
compatability.
There is a chance for a larger refactoring here.. It might be appropriate to
move some of the functionality from ConvertUtils into this new ConverterSet
object, for example setDefaultDouble(double value) (and then deprecating those
methods on ConvertUtils). Which would yield something like:
ConverterSet converterSet = ConvertUtils.getConverterSet("FormToDTO");
converterSet.setDefaultBoolean(false);
instead of:
ConverterSet converterSet = ConvertUtils.getConverterSet("FormToDTO");
converterUtils.setDefaultBoolean(false,converterSet);
(or use ConvertUtils.getDefaultConverterSet() to get the default set..)
On a side note, I initially thought I could use the name of the ConverterSet in
such situations, and do something like:
converterUtils.setDefaultBoolean(false,"FormToDTO");
However, that got me in trouble inside BeanUtils, because overloading some of
the methods with an additional String produced a method signature that was
already in use. Hence the requirement for a ConverterSet object.
I wanted to run this by the list because I would rather have input now before I
make a lot of changes, rather than after I make them :) If anyone has strong
opinions/comments/suggestions I would appreciate the feedback -- particularly
in regards to whether to expose the ConverterSet functionality through the
ConvertUtils (seems more in line with how the library currently works), or
whether to expose it through ConverterSet (seems more OO) . My preference is
the latter of those two options, however it means fiddling with a public API,
which might upset people...
Thanks.
-Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
