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:20:58 GMT
Answer inline:

> -----Original Message-----
> From: Ted Husted []
> Sent: Thursday, January 03, 2002 2:21 PM
> Paulo Gaspar wrote:
> > For such use it makes sense to have a specialized DynaClass and some
> > helpers,
> Agreed. I'm just thinking that the first thing I will do with a DynaBean
> is define a number of standard field or column helpers, that would
> correlate to the columns or fields in a database. 

In my implementation (the IRecord thing I talk about all the time) I am 
wrapping ResultSets with a very simple DynaBean which DynaClass is built
from a ResultSetMetaData. This object just works as a buffer zone that 
ensures reading columns in the right order (which is necessary with some
JDBC implementations) while doing some data conversion (lets say I am 
converting CLOBs to strings while also reading nested ResultSets into 

Then I read the above wrapped data into my "standard" DynaBean using a 

> Since this will be a common idea, we might want to consider a companion
> package to the DynaBean that defined these helpers. This could save us,
> and dozens of others, from each implementing our own, all with the same
> goals.
> There are are finite number of column types supported by the JDBC, so
> I'm thinking there could be a toolkit for generating these and rolling
> them into a DynaBean. 

Actually, I only give a special treatment to long types (BLOB, CLOB and 
so on) and nested ResultSets. All the rest I just read with getObject().
At the moment the buffering DynaBean ResultSet wrapper just says that all
columns are Objects although it uses special readers for the mentioned
special cases.

If I want to put data from a ResultSet in a Velocity template in a quick
and dirty way I just:
 - Create a DynaClass with the same number of properties and the same 
   names as the ResultSet wrapper, all these fields having Object as 
   their type;
 - Read the ResultSet into a List by repeating this steps:
     - Moving the ResultSet to the next row;
     - Using the above DynaClass to create a new "standard" DynaBean;
     - Read the data from the ResultSet wrapper into this bean;
     - Put the bean in the list.
 - And I put the above list in the template context.

(Actually, this is the version I use to cache data. There is another 
version where I put an Iterator that makes something similar without the
list, which is great for huge XML exports.)

If I want to do something fancy, I have a separate and more detailed 
DynaClass definition that follows my business logic needs and not so 
much the exact database types. Then, to read the data I just follow a 
method similar to the above quick and dirty case but using this 
DynaClass and setting the destination DynaBean to use an appropriate 
converter to turn the JDBC column objects into the appropriate types.

> Since any value can be represented as a String, such a helper might
> include a String buffer along with its native object, and could be very
> useful in ferrying input from the Web tier (which is String based) to
> the Business tier (which often needs native values). So each column
> helper would have a getXXX form and a getXXXString form. There may also
> be a setXXXBuffer form to enter data for later validation, and then a
> trigger for the valiation/conversion routine.

For many things I never go trough the String step. Some things I do when
 - I always convert any Number descendent to another Number type using 
   the methods in the Number interface (yes, I validate overflows);
 - I convert JDBC date/time types into java.util.Date... and I already
   miss converting also to other types;
 - I do not duplicate immutable objects if the source column type is the 
   same as the destination type.

I will try to post my Converter here in a couple of days. It is really 

> Elsewhere in this thread, I believe it's been suggested that an
> application might actually end up with two DynaBean definations, one
> String, one native. This often happens in Struts applications today. I'm
> just thinking that the leverage a DynaBean give us, makes a standard
> column helper package is an attractive idea.

You can also have helper methods to convert a Map of Strings into a 
DynaBean using a given Converter. Just to illustrate and without using the
correct method names that were proposed by Craig, such method would be
something 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);

> In practice, there would probably be domain-level validators/converters
> in the column helpers, and a model-level validator/convereter in the
> DynaBean itself. The idea being, for example, that first I make sure the
> datum could be a username or password (not too short, et cetera), and
> then I check to see if it actually registered as such. 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web

Have fun,
Paulo Gaspar

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

View raw message