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:ideas
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 yoursameregarding registries, but it sounds like a different approach to theweproblems 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. Beforetodiscuss *how* we are going to improve it, let's discuss *what* we wantinheritimprove. 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 notifconverters. 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 gooddifferent 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]
