So why don't we create a [convert] in the sandbox to play with the ideas here? (Maybe its a lack of hours in the day....) Stephen
----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
