Replying inline to describe what parts are in the code I just submitted:
On Tue, 7 Oct 2003, Sgarlata Matt wrote: > Hen reminded me I promised to do this, so here is a first crack at a mandate > for the proposed Convert sandbox component. One thing I was thinking about > is the name. Convert is rather dull, how about calling it Morph instead? I went with convert, but names are easy to change. > INTRODUCTION > Convert is a framework for converting an arbitrary Java object into any > other arbitrary Java object. The framework grew out of the conversion > mechanism provided by the ConvertUtils class of the BeanUtils framework. > One goal of the Convert framework is to integrate seamlessly with BeanUtils. Currently I'm assuming that BeanUtils would keep their ConvertUtils and ConvertUtilsBean. Those classes would wrap ConvertRegistry. Just a wild assumption at the moment. The system is Object->Object, though I suspect that 95% of converters will be String->Object or Object->String. I did have a Parser and a Formatter interface to highlight which ones were String->Object or Object->String, but hadn't used them anywhere so pulled them before commiting. > POTENTIAL FEATURES > - Provides a simple mechanism for converting an arbitrary Java object into > any other arbitrary Java object. Probably about 4 lines needed at the moment :) Not quite simple, but that can be wrapped. > - Seamlessly integrates with BeanUtils. > - Provides local-sensitive conversions for internationalization. Have ignored this. I think it's indicative of a larger problem of getting context arguments to a Converter. > - 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. > - (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. Implemented. Probably should only apply to the fromClass side, which just means that the ConvertRegistry should be a ClassMap of HashMap, and not a ClassMap of ClassMap. > - (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. I submitted ClassMap to Collections a while back, but it lacked a pluggable inheritence strategy. I've got a pluggable inheritence strategy in there now, so opinions on this would be much appreciated. > - Allows different converters to be used under different circumstances. For > example, one module of an application might require dates to be converted to > strings one way while another part of the application requires a different > standard for a different sent of users. Different registries? :) No idea on different inputs required other than fromClass/toClass. Context again. > - Provides a library of converters that may be extended by users of the > Convert framework. Need to look at Stephen's JODA converters for another batch. Need to finish coding CollectionConverter [problems in the number of Class types going on]. > - Provides a converter configuration mechanism that alleviates users from > the task of building their own configuration structures. Commons Configuration? Needs to be a separate jar to the central convert jar I think. > - Provides converters that operate on collections. For example, such a > converter might change a List of Person into a List of String. What gets really painful is, what if they want to convert a List of Person into a String[]. Just how do they specify that. Collection C of X to Collection C of Y is easy enough, but converting Collection type at the same time causes problems with the registering. This is part of why inheritence started to hurt. I think we should be able to request a converter of: ArrayList->String[] and it would be smart enough to build a chain of converters. Association rather than Inheritence. > - Allows the identity conversion (for example, String to String) to be > turned on or off. Nothing done on this. > PROJECT NAME > This project is still in the conceptual phase and a name has not yet been > decided upon. Possible names include: > - Convert > - Morph +1 Convert. It's been in informal use for quite a while. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
