commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [DynaBean] a couple of other existing projects...
Date Thu, 03 Jan 2002 16:56:49 GMT
Answer inline:

> -----Original Message-----
> From: James Strachan []
> Sent: Thursday, January 03, 2002 2:27 PM
> From: "Paulo Gaspar" <>
> >
> > ...
> >
> > I am just defending that even in such specific case it is not a
> > very good idea to extend the DynaBean.
> Agreed. Things like number or date range constraints or String
> patterns and
> other such validations sound like ideal metatdata to add to
> DynaClass. i.e.
> i18n and user context independent constraints. So maybe a DynaClass has a
> number of DynaProperties that can be extended to have validation
> rules etc.
> For things like type converters that turn Strings to and from other data
> types such as Number and Date, I was thinking these converters should be
> moved to a Controller as they can be environment or framework dependent.
> e.g. validation might result in a localized message being produced to be
> displayed in a UI. Or arbitrary formatting rules could be applied
> to display
> property values.
> So I was musing about the idea of having a BeanController facade to a
> DynaBean (or regular JavaBean) that used Strings and was responsible for
> doing the type conversions and validation messages, having Locale,
> ResourceBundles and whatnot, seemed better than forcing a DynaClass to
> understand these i18n issues.
> Another way around this could be to pass in some Context object
> which has-a
> Locale, Timezone, maybe a ResourceBundle and the DynaBean and having
> getString() / setString() methods that take a Context. Though this seems a
> bit clumsy, seperating this stuff out seems cleaner.

You can do a LOT with a simple Converter that is field aware. Thins means
that instead of the interface:

  public interface Converter
      Object convert(Class toType, Object newVal);

we could have

  public interface DynaBeanConverter
      Object convertProperty(Class toType, String propName, Object newVal);

Or we can have a mega controller that changes the DynaBean Converter when
needed (if the column to be set follows "exceptional" rules) or that just
uses an "external" Converter. That would probably have some method like:

  public class BigAndMeanBeanController
      public void copyData(Map source, DynaBean dest)
         // any weird stuff here

In this case you do might not miss the DynaBean having a converter
(although it might still help implementing it) but it also does not get
on your way.

The reason I keep insisting on a Converter attached to the basic DynaBean
implementation is that it eases a lot many simpler use cases:
 - Most of the times you use a DynaBean you will have to perform data
   conversion in a way that a Converter implementation can help a lot;
 - The few times you do not need conversion, you can skip it (I use a
   NoOpConverter to avoid "if (null == m_converter)" everywhere);
 - For more complex uses like you propose, the Converter-per-DynaBean can
   still help on its implementation and at least does not get on the way.

All this blah blah means that I think your ideas are very nice and valid
but they do not invalidate or are opposed by my Converter-per-DynaBean

> > > Since converters would have all kinds of optional contexts associated
> with
> > > them like Locale, Timezone and other stuff like maybe the user id or
> > > HttpSession, keeping such a controller seperate to the DynaClass, like
> the
> > > BeanController idea I suggested, would seem cleaner.
> > >
> > > e.g. a single 'customer' DynaBean instance could have a
> single DynaClass
> > > instance (which could be shared by other customer DynaBeans) but could
> be
> > > viewed using various different locales & timezones & users.
> So having a
> > > seperate 'controller' object for each context would seem to
> make sense,
> > > which just has-a reference to the DynaBean.
> >
> > Sure.
> >
> > But I still defended the option we previously discussed of having a
> > converter
> > attached to the DynaBean object (not the DynaClass) since it
> can make most
> > of
> > its uses simpler (e.g.: set the bean with a converter for the
> right Locale
> > and
> > just assign values to its fields).
> I think a simple facade might be cleaner, that takes care of the i18n and
> type conversion issues. i.e. a seperation of concerns. The
> DynaClass/DynaBean takes care of the typesafe properties and validation
> rules, the BeanController (or BeanConverter) takes care of the type
> conversion & i18n & validation messages issues. Though maybe adding an
> optional Formatter to the DynaProperty/DynaClass might help keep the
> metadata together, then just have a single helper class
> BeanController/Converter/View to do the i18 specific stuff.
> Still thinking aloud though.

Me too (thinking aloud).

I only defend the Converter-per-DynaBean (here I go again) at the
"standard" DynaBean implementation level because it would help on a very
common use pattern (wanting to get data from somewhere into the bean
following some simple type conversion rules).

The DynaClass extended metadata looks great for the case where you want
to define something like a form bean. Maybe implementing a DynaClass
descendant is a simple and convenient way to store such extended metadata
information. Maybe there are other ways.

I am still thinking how I am going to do this one too.

My experience with the Converter-per-DynaBean is some and very positive
but I still did nothing like you are talking about - although it is now
in my horizon.

> > > > Craig, I and others discussed several ideas that have a lot
> to do with
> > > > this stuff during the last couple of weeks.
> > >
> > > Just out of interest was this on a struts list or just privately?
> >
> > Just here in the commons-dev list. I do not use Struts.
> Ah in that case I read them; it was those ideas I was responding to. I was
> just checking there wasn't another discussion thread going on some place
> else.
> James

I will try to keep it here as much as I can.

Have fun,
Paulo Gaspar

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message