ok, that will be fine. Let me know when you are ready to have a look at it. I
can put it off for a couple days, and if I end up working on it we can just
work through and changes that you think are appropriate.
-ET
Quoting robert burrell donkin <[EMAIL PROTECTED]>:
> hi erik
>
> beanutils is on a bit of an unofficial code freeze at the moment (only bug
> fixes) since we need to release a 1.6.1 version soon to fix a problem in
> 1.6 (which breaks maven and jelly). if you could put your ideas on hold
> for a few days until this release is out the way, then i'd be glad to talk
> about refactoring then (if you're willing to hang around).
>
> - robert
>
> On Saturday, February 8, 2003, at 12:45 AM, [EMAIL PROTECTED] wrote:
>
> > 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]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
