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: [DynaBean] a couple of other existing projects...
Date Thu, 03 Jan 2002 10:21:04 GMT
Extending the DynaClass and using Converters would do most of what you
describe here. 

The DynaClass (metadata) part should be the only one having to be 
extended to avoid a complex DynaBean class structure. Then you can have
helper classes that use the extended metadata information to the tasks
you talk about (formatting, validation, etc.).

Trying to include these and other concerns in some DynaBean descendent(s)
will produce a monster hard to manage class(es). Separating such concerns
in separated helper classes with the help of extended metadata will have
the advantages of:
 - Simpler code;
 - Easier learning of its use (the user does not have to learn what he is
   not using).


Craig, I and others discussed several ideas that have a lot to do with
this stuff during the last couple of weeks.


Have fun,
Paulo Gaspar

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


> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Wednesday, January 02, 2002 7:20 PM
> To: Jakarta Commons Developers List
> Subject: Re: [DynaBean] a couple of other existing projects...
> 
> 
> In the course of the discussions, the idea of a "record" object has come
> up quite often, especially in relating the DynaBean to other object
> developers are already using. 
> 
> Perhaps we should think about a subclass of DynaBean, or another package
> based on it, that directly supported the idea of "field objects", and
> then made the fields appear like standard properties. 
> 
> So, you might create your own "RecordBean" class, and then in the
> constructor add several "FieldBeans", to represent the records. So there
> might be prewritten "DateFieldBeans" and "CurrencyFieldBeans", that
> would just add in the constructor (giving them labels and validators
> along the way).
> 
> These could then be exposed using both a native type and a String
> variation, so 
> 
> getDateString 
> 
> and 
> 
> getDate 
> 
> might both refer to the same "DateFieldBean". 
> 
> Using Struts as an example again, the ActionForms are being used like
> get*String properties for all the fields in a HTML form, and then there
> is a typed companion bean someplace that has the native version. Along
> the way someplace, we validate the get*String properties, and then move
> them over to a native bean. 
> 
> So along the lines of what Jim mentioned, maybe we could use the
> DynaBean to build another bean that could be used to accept String
> input, optionally validate it, and then expose it as a native type if
> validation passes. The DynaBean would encapsulate the field objects, so
> the fields could be used as JavaBean properties whereever JavaBeans are
> used now.
> 
> I'm not proposing we extend the DynaBean this way, but maybe to use it
> as base class for something that let us build more Swing-like controls
> that have a built-in String buffer along with a typed property. If you
> are building something from scratch, then this might be all you need. If
> not, then it would be a great vehicle for validating data before passing
> it along to a legacy object.
> 
> -- 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>
> 

--
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