commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Sgarlata" <sgarl...@crystalcognition.com>
Subject Re: [convert] description of project missing?
Date Fri, 12 Mar 2004 14:43:43 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message