Many thanks for all of the interesting and useful feedback to my original DynaBeans design proposal circulated last week. Based on this feedback I have made several changes (outlined below), and checked in some basic interface definitions that conform to these requirements into the Commons BeanUtils CVS repository. You can access them via anonymous CVS, or by downloading a nightly source distribution of BeanUtils (dated 2001-12-25 or later - my computer doesn't mind working on Christmas :-) from:
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-beanutils Major Changes And Enhancements: * At the suggestion of Michael Smith, separate out the information related to what properties are actually defined (along with optional restrictions on the data type, readability, and writeability of those properties) into a separate class called DynaClass. * Support "introspection" of DynaClass instances via the getPropertyDescriptor() and getPropertyDescriptors() methods. * Explicitly support a range of options so that DynaBeans developers can choose how much type safety and access control they want to enforce: - For each property, you can optionally declare the data type (i.e. a java.lang.Class instance) that all values for this property must be assignment-compatible with. - For each property, you can optionally declare that it is read-only or write-only. - For a given DynaClass, you can set a "restricted" state so that no further properties can be added or removed. * At the suggestion of Paulo Gaspar, add a Converter interface to define a formalism for data type conversions. An optional Converter can be associated with a DynaClass to process the input values specified to set() methods on the corresponding DynaBeans. Proposed Next Steps (Once Design Is Agreed Upon): (1) Integrate Converter into the existing BeanUtils support for populating bean properties, by adding a new BeanUtils method: public static void populate(Object bean, Map properties, Converter converter) (2) Implement convenient base classes for DynaBean and DynaClass to provide starting points for custom implementations. These classes should be sufficient for basic DynaBean use. (3) Integrate transparent support for DynaBeans into the existing PropertyUtils class. This will insulate developers using the existing APIs from having to worry about the new functionality provided by DynaBeans. (4) Implement "proxy" DynaClass and DynaBean wrappers around standard JavaBeans. (This sounds sort of backwards, but allows an application to be written *totally* in terms of DynaBeans if desired.) (5) Implement a convenient way to convert a java.sql.ResultSet (or RowSet) into a series of DynaBeans, where the corresponding DynaClass is synthesized based on the metadata of the result set. (6) Whatever we want to do next ... How does this sound? Craig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
