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 18:05:19 GMT
Answer inline:

> -----Original Message-----
> From: Ted Husted []
> Sent: Thursday, January 03, 2002 2:49 PM
> James Strachan wrote:
> > 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.
> David Winterfeldt's validator (already accepted as a Commons product)
> uses an XML configuration file to store these kind of properties for a
> field.

Interesting stuff!

> This can then be used in collaboration with a controller to perform a
> primia facia validation, and generate localized messages and what not.
> This would be the sort of thing that could also be stored with a column
> helper inside the DynaBean. The controller could then run down the
> objects stored in the DynaBean and trigger the validations/conversions,
> rerouting control if one or more fail.
> Of course, the DynaBean would not need to be aware of any of this, it is
> just encapsulating the column helpers. The controller could be calling
> the triggers on DynaBean members (which it would know are all column
> helper objects).
> I'm thinking we could merge what David's validator does with a column
> helper that also supported a data-entry buffer, and define everything
> about a column in one place. You know, like Access or FileMakerPro ;-)

What I am trying to find out is an as-light-as-possible implementation of
a DynaBean that allows to do all this stuff.

Since this is stuff that depends on a context (what is the Locale of the
user, i18n, current form, etc.) it should be in an external Controller as
James suggested or in the DynaBean as I like (for simple enough stuff).

The DynaClass is one for the whole app. Any properties and rules you set
there are application wide. If you set a DynaClass for a "form bean"
DynaBean, it will probably only be useful for that form - and this could
be very appropriate anyway.

If you have column helpers per DynaClass (as I have for some wrappers)
they are application wide too.

OTOH, If you have column helpers per DynaBean, the DynaBean might become
an heavy object - at least an additional object per property per bean.

Lets evolve a bit the per-property-converter of my previous post and call
it an input filter:

  public interface InputFilter
      Object filter(int propIndex, Class destType, Object newValue);

If you have an (optionally doing nothing) InputFilter per DynaBean with
its filter method called to process each value being assigned to a
property you can do a lot with it in terms of per field type conversion
and validation (or you can do nothing).

You can implement an InputFilter to apply generic type conversion rule,
per-property type conversion rules, same thing for validation.

And you can swap InputFilter at each stage of a processing pipeline
depending on the needs of that stage.

You can make it very light:

  public class NoOpInputFilter implements InputFilter
      public final Object filter(int propIndex, Class destType, Object
      {   return newValue;

Or you can make it as complex as you describe.

For global bean validation you can implement an extended interface:

  public interface PostValidatingInputFilter extends InputFilter
      void validate(DynaBean updatedBean);

Then helper methods or controllers can do things like:

public class DataPumpHelper
    public static void copyByName(Map source, DynaBean dest)
        final String[] propNames = dest.propNames();
        for(int i = 0; i < propNames.length; ++i)
        {   String pName = propNames[i];
            if (source.containsKey(pName))
                dest.set(pName, source.get(pName));
                dest.set(pName, null);

        InputFilter inpFilter = dest.inputFilter();
        if (inpFilter instanceof PostValidatingInputFilter)

Of course that both the InputFilter.filter() and the
PostValidatingInputFilter.validate() methods should throw exceptions when
something is wrong/invalid. I am just not very sure if they should be
RuntimeException's but that is what I am doing for data conversion.

The above DataPumpHelper.copyByName() could collect those exceptions to
provide complete information on all that goes wrong.

> The nice part about doing this with a DynaBean, is that we get what
> appears to be a standard JavaBean, but is actually being assembled from
> component objects.


> Again, this would not be in the DynaBean package per se, but another
> package using the DynaBean as a proof of concept.
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web

Keep the ideas flowing and ave fun,

Paulo Gaspar

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

View raw message