Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3C34A0D0.1F10D830@apache.org>
Date: Thu, 03 Jan 2002 13:20:00 -0500
From: Ted Husted <husted@apache.org>
Organization: Apache Software Foundation / Jakarta
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [DynaBean] a couple of other existing projects...
References: <NEBBJJIICDPIINBNIJHJOEIOMNAA.paulo.gaspar@krankikom.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paulo Gaspar wrote:
> 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
> obsession.
> =;o)

Agreed. 

Nothing I'm talking about affects the DynaBean implementation. I'm
thinking of a package that would put the DynaBean to good use. 

The objects in this package may also have their own converters, but that
would not affect the design of the base DynaBeans.

Paulo Gaspar wrote:
> For many things I never go trough the String step. Some things I do when
> converting:
>  - 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
> simple.

Where the getXxxBuffer comes into play is with data validation and
CORRECTION. The idea is that you need to buffer whatever they input, so
you can return it to them for correction (without relying on the browser
back button). 

The getXxxString accessor may be just a standard converter for the type,
or may return a formatted version. For example a telphone number may be
stored as all digits in the database, but punctuated on the page. So if
I want the raw version, I can ask for getXxx when I want the formatted
version, I ask for getXxxString. In some case, they may both return
Strings, but one might be formatted. 


James Strachan wrote:
> Agreed. Maybe a DynaClass could be constructed from a list/array of
> DynaProperty objects, then we could have a library of derived DynaProperty
> classes for standard properties, default values, range contraints etc.
> 
> e.g.
> 
> String[] sexes = [ "m", "f" ];
> DynaProperty[] properties = {
>     new StringProperty( "name" ),
>     new PercentProperty( "score" ),
>     new DateProperty( "birthday" ),
>     new ChoiceProperty( "sex", sexes )
>     new DynaProperty( "foo", Foo.class )
> };
> DynaClass personClass = new DynaClass( "Person", properties );
> DynaBean person = personClass.newInstance();

That's the general idea, though these do not have to be Dyna anythings.
I'm thinking of a conventional base object to represent a column, with
subclasses to represent the different types. The object would have
properties representing the column name, label, type, range, validation,
converter, state, and so forth. 

In a real application, we are already creating all this someplace, it's
just getting spread around.

This package does not even need to be DynaBean-aware, and I'm sure
people have done similar things in the past. But, if we insert something
like this into the DynaBean at initialization, they get exposed as
ordinary JavaBean properties, rather than as some custom class. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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