Hi Stephen, Thanks for your reply. Once we get everyone's input, I'll post a final list that we can vote on and can be included on the website. Maybe we should split up the list into "planned features" and "other ideas"? Point-by-point comments below:
> > - Seamlessly integrates with BeanUtils. > Up to [beanutils] Actually I think the intention here was that [convert] would build this. For example, we could write a ConvertAdapterConverter class that conforms to the BeanUtils Converter API but actually carries out the more powerful conversion mechanisms in [convert]. Register this class with BeanUtils and you have the power of [convert] with the API of [BeanUtils]. > > - Allows converters to be written at an arbitrary level of granularity. > For > > example, fine-grained converters can only convert objects of a single > class > > to objects a single other class. Course-grained converters can convert an > > object of a single class to objects of a multitude of different classes. > Need a use case here. Most conversion is from class to class (or subclasses) I think I'm the one that originally advanced this idea. My goal here is to cut down on the number of classes that need to be written. For example, converting BusinessObject1 to BusinessObject2 is probably going to be a fairly fine-grained converter. However, converting a PersonDAO to a PersonForWebServicesTransfer and converting a Person to a PersonForEJBTransfer might want to combine multiple converters into a single class. If you don't like this use case, let's just scratch the idea. It might be simpler to include only the class-to-class conversion scheme. > > - (Related to the point above) Provides an automated conversion lookup > > mechanism that allows conversions for types that have not been > specifically > > registered to be attempted by traversing the inheritance hierarchy of the > > classes involved in the conversion. > > - (Related to the point above) Provides a Go4 Strategy that defines how > > inheritance hierarchies are searched for converters. Some obvious > > Strategies are included in the Convert framework. > This specifies implementation (the interface hierarchy). There are > alternatives - see convert2. Maybe this should be moved to the "other ideas" section? > > - Provides a converter configuration mechanism that alleviates users from > > the task of building their own configuration structures. > -1. IMHO convert should be configured only by java methods, other config is > out of scope because everyone wants to do it in their own way. I think this might have been Henri's idea, and I don't think he meant making another XML config file. I think the idea was to allow you to have more than one set of conversion rules in memory at once. This would allow different conversions to be used in the same JVM. That's better than [BeanUtils] because if you need different converters registered for different apps with [BeanUtils] then I think you're basically out-of-luck. > > - Allows the identity conversion (for example, String to String) to be > > turned on or off. > Why? This was Henri's idea. Henri? > Stephen Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
