I'm not sure I understand your post. It may be early to discuss an adapter between convert and beanutils because convert isn't even in the sandbox yet, but here's what I was thinking. Beanutils has a register(Converter, Class) method that gives each class a converter. Convert would be defining some type of mechanism that takes into account a "from" class and a "to" class for the conversion. I was thinking we could construct Beanutils converters dynamically based on the rules defined in Convert and plug those into the existing ConvertUtils.register() method. Does that make sense? We're basically aggregating all the fine-grained rules defined with convert into the coarse-grained class-level converter that beanutils expects.
Matt ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Monday, September 29, 2003 5:28 PM Subject: Re: [beanutils] some ideas > the difficult bit is working out the right abstraction for the strategy. > due to backwards compatibility issues, we'd want to get it right before > beanutils is released again. but this is actually a more general issue > which applies to all the new beans. > > - robert > > On Monday, September 29, 2003, at 01:44 PM, Sgarlata Matt wrote: > > > This sounds like a good approach. I would like to volunteer to write the > > adapters between [convert] and [beanutils]. > > > > Matt > > ----- Original Message ----- > > From: "robert burrell donkin" <[EMAIL PROTECTED]> > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > > Sent: Monday, September 29, 2003 6:19 AM > > Subject: Re: [beanutils] some ideas > > > > > >> +1 > >> > >> my preferred solution would be to create a sophisticated conversion > >> component starting with new backwards compatibility issues and make the > >> conversion in beanutils pluggable. beanutils is going to need an > > 'optional' > >> package to allow additional non-core dependencies sooner or later. i'd > >> advocate shipping an adapter in there rather than extending the core > >> dependencies of beanutils. > >> > >> - robert > >> > >> On Sunday, September 28, 2003, at 10:32 PM, Stephen Colebourne wrote: > >> > >>> 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] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
