Some remarks inline:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Craig R. McClanahan
> 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.
This separation as lots of advantages and I suspect I still do not know
them all.
I did so in my ("Record") implementation of DynaBean implementation only
expecting to save space, since I often cache "Records" and the DynaClass
part can often take more space than most DynaBean data parts.
The fact is that there are many other advantages that still keep popping
up. For instance, for my wrapper implementations, only the DynaClass part
changes implementation and just on little bits like property "getter" and
"setter" implementations. And it does not matter if the wrapped object is
a bean or even a ResultSet.
> * 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.
In my experience the data type should be already in the most basic
implementation or you have not much than a Map with an indexed (int)
access.
For very simple usage you can still simplify defining a DynaClass by
having some simple way of declaring java.lang.Object as the type of
every property.
> - For each property, you can optionally declare that it is read-only
> or write-only.
I leave that to specialized implementations.
I often must make a DynaBean read-only and sometimes I have to declare
it read-only straight from the DynaClass level. But field by field
restriction does not happen often and always having it there weights on
performance.
> - For a given DynaClass, you can set a "restricted" state so that no
> further properties can be added or removed.
I always use it that way.
It is very problematic if a DynaClass is mutable. I mean, imagine the
side effects of changing the DynaClass being used by a zillion of beans.
It simplifies a lot the code and the predictability of its behavior to
have make DynaClass immutable. To build it you just pass an array or a
list of "DynaProperty" definitions to its constructor.
What I am missing is to add extra "untyped" properties to a specific
DynaBean, but that is a specialization for which I use a descendent
class.
> * 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.
Quite often it is better to associate the converter to the DynaBean.
I already covered this case quite a bit in my answer to Francois.
> 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)
I could contribute my Converter.
We agree on this interface, you could use a base implementation and I
could use some improvements to it.
=;o)
> (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.
I have something, but my interfaces are quite different.
> (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.
You can also do a lot just in terms of DynaBeans if you use wrappers.
> (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.)
And helps on applying conversion.
> (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.
See my DynaBean wrappers + DynaIntrospector remarks on my answer to
Francois.
> (6) Whatever we want to do next ...
>
> How does this sound?
Some remarks to the code you posted.
DynaClass:
- As explained above, should ALWAYS be immutable. No add() methods in the
interface. The implementation constructor(s) could accept lists and/or
arrays of PropertyDescriptors;
- Should not care about Converters, which should be at the DynaBean level,
as explained in a previous post;
- Interesting the idea of using straight PropertyDescriptor for the
properties. I am checking if I can do just that with all the
implementations I have. (Yes, it should be obvious to use what "is
already there".)
=:o)
DynaBean:
- I still do not use indexed properties but I see how they are needed to
cover all types of JavaBean properties;
- However, why mapped properties are needed, as in
public Object get(String name, String key);
public void set(String name, String key, Object value);
This has no parallel in JDK 1.3 beans and it looks to me like its
usefulness can be achieved handled just by having some other type of
property, e.g. a Map property.
(So, my question is "Why?".)
> Craig McClanahan
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
