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 Wed, 17 Mar 2004 18:42:22 GMT
Hi Stephen,

Here is updated info for the website based on your comments.  What do you
think?

POTENTIAL FEATURES
- Provides a simple mechanism for converting an arbitrary Java object into
any other arbitrary Java object.
- Seamlessly integrates with BeanUtils through the use of an optional
package.
- Provides local-sensitive conversions for internationalization.
- 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.
- Allows different sets of 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 set of users.
- Provides a library of converters that may be extended by users of the
Convert framework.
- Provides converters that operate on collections.  For example, such a
converter might change a List of Person into a List of String.

Matt
----- Original Message ----- 
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, March 15, 2004 6:37 PM
Subject: Re: [convert] description of project missing?


> From: "Matthew Sgarlata" <sgarlatm@crystalcognition.com>
> > > > - 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].
> [convert] cannot depend on [beanutils] in its core. However, I suspect
that
> [convert] will need an optional library design for things like this.
>
>
> > 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.
> Multiple Converters differently setup is a must.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


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