commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <>
Subject Re: [Design Discussion] DynaBeans - Round 2
Date Tue, 25 Dec 2001 01:44:48 GMT
The breaking out of the DynaBean definition into a separate class - the
DynaClass - is a good idea.

I haven't looked at the interface yet, but there is a method to, "given
a DynaClass, create for me an empty DynaBean"?

I also recommend the ability to mark a DynaBean instance "read only",
possibly even without providing a mechanism for reversing this status.
In this way, a DynaBean which may have been created by a persistence
layer can be "torn off" into a disconnected, read-only Value Object.



On Mon, 2001-12-24 at 16:51, Craig R. McClanahan wrote:

    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:

    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:   <>
    For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message