commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [convert] description of project missing?
Date Fri, 12 Mar 2004 01:22:28 GMT
From: "Matthew Sgarlata" <sgarlatm@crystalcognition.com>
> Last October I helped write a description of some of the goals for the
> [convert] project.  I noticed the nice Maven site that's up for the
project,
> but the description I helped write isn't up there.  The description isn't
in
> CVS either.  I just tried to search for the thread where this was
discussed
> on Google, but no luck.  Here is the initial draft I sent to the
commons-dev
> list.  Anyone (Henri?) know where an updated copy is?  I know Craig had a
> bunch of comments about this initial list I sent out.
I've not seen any CVS copy of this, but there's no reason why this can't be
the basis of something this time ;-)

> 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.
+1

> - Seamlessly integrates with BeanUtils.
Up to [beanutils]

> - Provides local-sensitive conversions for internationalization.
+1

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

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

> - 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.
+1, see convert2 Converter

> - Provides a library of converters that may be extended by users of the
> Convert framework.
+1

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

> - Provides converters that operate on collections.  For example, such a
> converter might change a List of Person into a List of String.
+1
> - Allows the identity conversion (for example, String to String) to be
> turned on or off.
Why?

Stephen



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message