commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Convert] Mandate (draft)
Date Wed, 08 Oct 2003 05:06:21 GMT
+0 on the general concept of exploring a conversion support package.  
More comments below.

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?
See previous mails.  -1 on any name that is not totally focused on the 
functionality being supported.

>I don't know what format we want this mandate in, so for now I have a copy
>in M$ Word that I will convert (pun intended) to the appropriate format
>later.  Here is a text copy of it:
If you don't publish in some open format (txt, html, ...), you have just 
lost the majority of your potential audience :-).

>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.
>- Provides a simple mechanism for converting an arbitrary Java object into
>any other arbitrary Java object.
>- Seamlessly integrates with BeanUtils.
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.

>- Provides local-sensitive conversions for internationalization.
How does this go beyond what the locale subpackage of BeanUtils already 

>- 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).

>- (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).

>- (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
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.

>- Provides converters that operate on collections.  For example, such a
>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.
You 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.

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.

>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".


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message