> > I think it is possible to add more methods for ConvertUtils like method
> > useful for DynamicProxy :
>
> Does this mean you think ConvertUtils should be broken out from beanutils
> into its own commons area?
I am not sure it is good to have a lot of "small" packages.I have no ideas
abaut refactoring.
I think it can be good to add some methods for transformations,
debuging(String toString(Object o) ).
It is not very good to add Enhancer, it is better to have it in BCEL utils,
I will try to move this code from SimpleStore, this project is not about
some
kind of byte code generators.
>
> > And I think Proxy generator from sandbox-simplestore can be useful for
> this
> > project.
> > This generator can be used in frameworks like JODA, SimpleStore or
AltRMI
> .
>
> Yes, I have had a quick play with the Enhancer class. (I've also posted a
> question to BCEL mailing list on a related topic). Have you had any luck
in
> getting Enhancer adopted by BCEL? It seems to be a little misplaced in
> simplestore.
> Stephen
>
> > > Hi,
> > > I have been examining the beanutils Convertor/ConvertUtils classes
with
> a
> > > view to using them instead of the type convertor code I have written:
> > > http://www.scolebourne.eurobell.co.uk/JodaTypeConvertor.zip
> > >
> > > Currently I have found the following differences:
> > >
> > > 1) The Joda type convertor is called when an object needs to be
> converted
> > to
> > > a String. ConvertUtils does not do this. This is essential for classes
> > where
> > > the toString() is for debugging and not a formal string (such as
> > > GregorianCalendar).
> > >
> > > 2) Joda type convertors support a dynamic convertor creation
mechanism.
> > > Basically, you specify that a particular convertor class is to be used
> for
> > > subclasses of a particular class. When required, a new instance of the
> > > convertor is created, to which the subclass is passed. This is
essential
> > for
> > > a case like the standard Enumeration pattern in Java, where I don't
want
> > to
> > > have to write a type convertor for each enumeration subclass, instead
I
> > just
> > > want to write a convertor for the superclass.
> > >
> > >
> > > Any feedback on these differences/possible enhancements? I am willing
to
> > > contribute to improving ConvertUtils if required.
> > >
> > > Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
