Sgarlata Matt wrote:
Hen reminded me I promised to do this, so here is a first crack at a mandateSee previous mails. -1 on any name that is not totally focused on the functionality being supported.
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 don't know what format we want this mandate in, so for now I have a copyIf you don't publish in some open format (txt, html, ...), you have just lost the majority of your potential audience :-).
in M$ Word that I will convert (pun intended) to the appropriate format
later. Here is a text copy of it:
That only works if you push us BeanUtils committers towards a portable way to replace the standard singleton instances that are available in the latest nightly builds, plus convince us why it's important enough to go to a 2.x version number (adding new dependencies is a very non-trivial exercise for existing users of a Commons package, so i'm -1 on adding any without a change to the major verson number.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.
POTENTIAL FEATURES - Provides a simple mechanism for converting an arbitrary Java object into any other arbitrary Java object. - Seamlessly integrates with BeanUtils.
- Provides local-sensitive conversions for internationalization.How does this go beyond what the locale subpackage of BeanUtils already provides?
- 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.
My advice is to implement coarse-grainedness based on inheritance hierarchy (if there's no converter for java.sql.Date, use the one for its superclass java.util.Date instead).
Yep.- (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.
And don't forget to make the lookup mechanism work in a servlet container, where individual webapps might want individual resolutions (even if the conversion package is in a parent class loader).
Class libraries like this should provie configuration mechansims should be provided through APIs. Support for automatic processing of things like properties files or XML configuration documents should be optional ease-of-use features, not fundamental requirements.- (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. - 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. - Provides a library of converters that may be extended by users of the Convert framework. - Provides a converter configuration mechanism that alleviates users from the task of building their own configuration structures
- Provides converters that operate on collections. For example, such aYou haven't mentioned the most important consideration -- whether conversion is an Object->Object use case, or whether it's actually bidirectional (Object->String and String->Object). There is room in the world for conversion packages that support both viewpoints; however, pretending that a single Object->Object package can support both is the biggest weakness in the current BeanUtils conversion model.
converter might change a List of Person into a List of String.
- Allows the identity conversion (for example, String to String) to be
turned on or off.
FWIW, JavaServer Faces is likely to end up with an explicitly bidirectional Object->String and String->Object) conversion API. This makes sense because JavaServer Faces is rooted in an environment that represents nearly all business data as Strings. But it's worth evaluating this pattern for general purpose use as well.
+1PROJECT NAME This project is still in the conceptual phase and a name has not yet been decided upon. Possible names include: - Convert
- Morph-1 on any foo-foo name, as per my previous response. "Morph" isn't the worst possible choice, but it's definitely worse than "convert".
MattCraig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
