commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [Design Discussion] DynaBeans - Round 2
Date Fri, 28 Dec 2001 00:10:17 GMT
Snipping to deal with a few questinos and thoughts ...

On Thu, 27 Dec 2001, Paulo Gaspar wrote:

> 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.

I'm thinking that there will be two common use cases -- one where you
don't want to bother predefining the datatypes, just grab whatever's there
and put a facade around it (HTTP request parameters), and another case
where you want to have type safety but still dynamically define the set of
supported properties.

But the important benefit is a common *access* API for applications using
the DynaBeans without caring which "kind" they are -- the same benefit
you've created by putting IRecord wrappers around standard JavaBeans.

> 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.

I figured that would be the default, along with read/write access being
the default.  You'd have to go to extra efforts to change either.

> >   - 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.

Read-only-ness of the bean is really more useful at the DynaBean instance
level, right?  Once you've populated all the properties themselves, you
just flip the switch to avoid inadvertent changes later.

> >   - 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.

Or define a mapped property (see below for more).

> > * 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.

As discussed, it's not mentioned in the interfaces now ... Converters are
an implementation level featuer.

> > 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)

That would be quite useful.

> > (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.

That's undoubtedly true.  However, *one* of the use cases for me is to let
applications already using BeanUtils and friends (which means, among
others, all Struts-based apps) to be able to transparently leverage
DynaBeans underneath the BeanUtils APIs.

At the same time, I think DynaBean API wrappers around standard beans give
you a similar benefit if you're starting from DynaBeans.  You probably
wouldn't deliberately choose to use both, but now you'll be able to go in
either direction.

> > (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;

In the interest of simplest possible basic interfaces, I agree with this.
However, I'm thinking that there will be cases where mutable DynaClasses
will be useful - but that can be a specialization later.

>   - 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)

It has it's own wrinkles at implementation time, but seemed like a good
idea -- especially since I was already using them in BeanUtils.

> 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?".)

Mapped properties have several motivations for me:

* To cover all the things that BeanUtils and PropertyUtils already
  know how to do (for the goal of transparent access to DynaBeans
  through BeanUtils APIs).

* Lend themselves naturally to an expression language syntax (BeanUtils
  uses square brackets for real indexed subscripts and parentheses for
  String-based "subscripts").

* Several projects that try to use XPath syntax to navigate Java
  object trees (instead of XML documents) have a very elegant mapping
  of mapped properties to the search syntax.  This has the effect of
  reducing the amount of knowledge that the user needs of the "actual"
  shape of the objet tree being navigated.  You just need to know the
  access expression, and let the underlying expression evaluator figure
  out if you're referencing a scope, a bean, a Map value, or a property.
  (One example of this kind of package is the JXPath commons project).

* Allows you to have an "extensible" DynaBean even if the underlying
  DynaClass is immutable.

> > Craig McClanahan
> Have fun,
> Paulo Gaspar


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message