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.
Thanks,
Bryan
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:
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]>
