commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sgarlata Matt" <sgarlata_m...@bah.com>
Subject Re: [beanutils] some ideas
Date Sun, 28 Sep 2003 07:43:36 GMT
----- Original Message ----- 
From: "Henri Yandell" <bayard@generationjava.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Saturday, September 27, 2003 10:39 PM
Subject: [beanutils] some ideas


>
> I'm interested in the convert stuff. Especially the Object->String stuff.

Me too :)  I'm just starting to play with this stuff and realize how
powerful it is.

> First a question on Dates. Why not support for java.util.Date? It seems
> that there's not much point having SqlDateConverter, it should just be
> DateConverter based on util.Date.

Good question; I can't guess why java.sql.Date would be provided and
java.util.Date would not (if anything, it seems like it should be the other
way around).

> Secondly...I think the Convert system needs improvement. The basic problem
> is highlighted by:  ConvertUtils.register(Converter, Class).
> It ought to be:  ConvertUtils.register(Converter, Class from, Class to).

I agree this may be more intuitive and easier to program, but I think the
current system does the job (see additional comments below).

> I want to register a Converter for Date->String and another for
> Date->sql.Timestamp.

I believe this is already possible.  The calls would be
ConvertUtils.register(DateConverter, java.util.Date);
ConvertUtils.register(DateConverter, java.sql.Date);

Here is pseudocode for DateConverter:

DateConverter {
  convert(Class toClass, Object input) {
    if (toClass.equals(java.lang.String.class))
      return input.toString();
    else if (toClass.equals(java.sql.Date.class))
      return new java.sql.Timestamp(((Date)input).getValue());
  }
}

> Solutions could be either:
>
> 1) Improve the system for the mapping converters so it is many-to-many.
>
> 2) Create a hierarchy structure. A ConvertUtilsBeansConverter could be
> plugged in to handle a class, and would contain its own batch of
> Converters.
>
> Any ideas?

I think the Converter interface is fine, but could perhaps use some better
documentation and examples (in the JavaDoc... the converters in the
distribution seem more general-purpose than will be the converters a user
needs to create).  I do like the idea of adding a new
ConvertUtils.register(Converter, Class from, Class to) method.

> Hen

Matt


Mime
View raw message