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 Wed, 17 Mar 2004 22:41:02 GMT
Website updated, thanks
Stephen

----- Original Message -----
From: "Matthew Sgarlata" <sgarlatm@crystalcognition.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, March 17, 2004 6:42 PM
Subject: Re: [convert] description of project missing?


> 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


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