commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [Design Discussion] DynaBeans - Round 2
Date Thu, 27 Dec 2001 21:13:30 GMT
Answer inline:

> -----Original Message-----
> From: craigmcc@krankikom.de [mailto:craigmcc@krankikom.de]On Behalf Of
> Craig R. McClanahan
>
> ...
>
> > From: Rey Francois <Francois.Rey@capco.com>
>
> > Now the reason for this email is because I had a quick glance
> at the code
> > that Craig committed earlier, particularly the Converter interface:
> >     public Object convert(Class type, Object value);
> >
> > I had to crate a similar interface in a data mapper framework I
> developed,
> > however in the signature of the conversion method I included an
> additional
> > parameter for the Locale. Without it, support for internationalized
> > conversions is difficult. Perhaps this could be added in a new
> method of the
> > Converter interface, or perhaps it can be included in another interface
> > extending the Converter, e.g. LocalizedConverter extends Converter.
> >
>
> I think it makes sense to have an additional convert() method with the
> Locale as an extra argument.  It also seems reasonable to add it to the
> same Converter interface -- a Converter implementation that didn't care
> about localization could just punt and call the two-argument version,
> while everyone building Converters would be reminded that they really
> should think about this.

I think it is better to have a Converter per Locale.

Locale is only ONE aspect of a broader range of Context dependent
conversions. Another simple case is having a String that is converted to
a File using a base directory in case the String holds a relative Path,
as it happens in Ant.

I became an adept of the Converter idea after reading the code of Ant's
Myrmidon proposal by Peter Donald. There he uses a third parameter for
the convert() method - the Context.

Context is a very powerful concept from Avalon which could cover any
context dependent situation as Locale, base directory, etc. But using it
complicates a bit the use of the Converter and it is a parameter being
passed all the time, even when it is not needed at all.

For me it makes more sense to have a different Converter for each new
specific situation. You can have a Converter implementation that accepts
the Locale (or a Context) in its constructor and you can have a Map of
pre-built Converters per Locale.


> > ...
>
> One way to incorporate conversion into DynaBeans directly would be to add
> additional set() method signatures that take a Converter along with.
> However, I'm inclined *not* to do this at the moment:

It makes more sense to have a Converter per DynaBean (not DynaClass) and
change it when needed. IMO this provides the easier use considering the
typical use of a DynaBean.

So, you would have:

    myDynaBean.setConverter(localizedConverter);
    // and now read all the Servlet request parameters into the bean...
    ...

or
    myDynaBean.setConverter(fromSqlConverter);
    // and now read all the ResultSet columns into the bean...
    ...


> * You can always do your conversion separately ahead of time
>   (looking up the property data type using getPropertyDescriptor()
>   as necessary).

Painful, as I described in my answer to Francois.

> * You *must* do the conversions ahead of time if you're dealing with
>   "real" JavaBeans instead -- in the way that PropertyUtils does
>   underneath the covers, so this would maintain consistency.

Or use a DynaBean wrapper, as described in my answer to Francois.


> That being said, we could leave conversions to the user in the case of
> standard DynaBeans (and access them via PropertyUtils), but implement
> conversion capabilities in things like BeanUtils.copyProperties() that
> does the right thing for DynaBeans just like it would for standard beans.

Then BeanUtils must know what Converter to use.

A good DynaBean + Converter + DynaBeanWrapper implementation obsoletes
most of the uses of BeanUtils or PropertyUtils because of its simpler use
and some additional flexibility.

Again, some longer examples given in my previous answer to Francois.

> ...
>
> > We could implement transparently the use of converters in the
> > set() method like Paulo Gaspar suggests in order to populate a
> DynActionForm
> > from a value object (or business object). However we would
> probably need to
> > do the reverse conversion in the get() method so that we can populate a
> > value object with a DynActionForm.
>
> Yep ... conversions both ways are required.  My bet at this point is that
> it will be easier to design this kind of thing as two separate converters,
> but we'll see.

YES!
As many Converters as needed but really simple to build
=:o)

I build them by adding per-type rules and having several rule-sets.


> > This would require some ways of passing
> > the target type to the get() method so it can select the appropriate
> > converter.
>
> As above, I would not suggest embedding the conversion into the DynaBean
> directly -- that's something you can either do externally on a property by
> property basis, or generically by extending BeanUtils.copyProperties()
> with a Converter argument.

I like all those.

> Regular JavaBeans don't have built-in converters.  Therefore, I don't
> think DynaBeans should either.

For me, the BIG improvement of DynaBeans over regular beans is having a
converter that acts only on the set() method.


> > ...
> >
> > Fr.
> >
>
> Craig

Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de



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


Mime
View raw message