commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject [Design Discussion] DynaBeans - Round 2
Date Mon, 24 Dec 2001 23:51:58 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message