On Sun, 28 Sep 2003, Sgarlata Matt wrote:

> Robert, thanks for pointing out that these issues have been discussed
> before.  Here are the two threads I could find:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg17188.html
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg05085.html
>
>
> Hen, let me be honest and say I'm not quite sure I understand all your ideas
> regarding registries, but it sounds like a different approach to the same
> problems discussed in the first thread above, right?

Yep. One of my options was to use the first one, where you have a
specialised Converter class. However this is a bit of a hack and really
the internals of ConvertUtils should just move from 1 dimensional to 2
dimensional. The idea I was tending towards would have ConvertUtils use
'ConverterSet's internally.

For the second email, Stephen and I have remakred to each other before
about the desire to get convert-utils more usable by other projects.

> All, it sounds like there is interest in improving ConvertUtils.  Before we
> discuss *how* we are going to improve it, let's discuss *what* we want to
> improve.  From what I can tell these are the deficiencies that have been
> identified so far:
> - Converters must be registered for each type, and subtypes do not inherit
> converters.  In one of the threads above someone mentioned this is
> particular a problem when dealing with Enumerations.

Yep. One of the problems here is how to define the inheritence lookup
policy. Effectively we have the multiple inheritence problem.

I've a ClassMap class that I use for these kinds of things, but it imposes
a certain lookup policy and is not generic.

> - (I'm not as sure about this) ConvertUtils only allows a single set of
> conversion rules to exist, since it is a static class.  It would be good if
> different conversions could be defined for different circumstances.

Kind of. If you dig into the code enough, you can lug ConvertUtilsBeans
and ConvertUtils around a bit I think, but it doesn't look like a simple,
easy to do piece of code. It needs to be much easier.

> Can anyone think of any others?

Need lots more in the way of standard converters. Not all standard
converters need be defaults.

Need a wrapper for convert utils that provides a configuration system so
people are not always building their own structures. This should not be
mandatory however.

Needs to still fit BeanUtils' needs.

Collection converters need to support internal Converters. ie) might want
to turn an ArrayList of Person into an ArrayList of String. Perhaps? :)

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to