On Tue, 21 Aug 2001, Gregor Rayman wrote:
> "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
> > > I thought, BeanUtils.populate() tries to copy every parameter to a
> property.
> > > So it enumerates the request parameters, not the properties. If the
> > > enumeration of properties was necessary, it could be done by some sort
> > > of configuration of the bean. So the bean would be able to change
> > > its properties list during the runtime. This is not a big problem, since
> > > we can use string keyed properties in cases where the names cannot be
> > > determined during deployment.
> > >
> >
> > It does iterate through the request parameters -- but ultimately, it needs
> > to be able to decide whether a particular request parameter matches the
> > name of a valid property or not. And this needs to work whether or not
> > the dynamic bean already has a value for that property.
>
> The problem with dynamic properties is, what has the bean to know, whether
> a property exists. In case of dynamic properties the bean can have
> unlimited number of properties since the property can be dynmically created
> when used.
>
Yes, that is the crux of the problem, all right.
I've seen different implementations of the "dynamic properties" concept
take different approaches to it. Almost everyone starts with "all the
dynamic properties that are *currently* defined are valid", but they
change from there. The positions can then range from:
* Any property at all can be legally created on the fly (i.e.
a BeanUtils.populate() type call would create properties for *all*
request parameters, because it would not know any better)
* Only properties on a configurable list are legal (but the list
can be dynamically modified.
> If the bean has to return a final list of its properties, then we have to
> decide, what the answers to the following questions will be:
>
> a) where to decide, which properties exist? Configuration file? Interface
> the bean can implement?
> b) is this list related to each bean instance or to its class?
>
> My preferences were:
>
> a) The bean has to implement an interface, which will return an array
> of its property descriptors. The implemnetation could depend on a
> configuration file. We could provide some helper classes.
> (This would also allow other kinds of properties without touching
> PropertyUtils).
>
> b) If we will use an interface for a) then the bean itself could decide.
> (But what about caching).
>
Version (a) is very close to my favorite approach -- create an extension
of the BeanInfo concept in JavaBeans. Since you control the
implementation of the BeanInfo class, you can decide how the list of
properties is created (and it can change dynamically based on
circumstances for a particular bean). Further, this fits in to what
BeanUtils is already using for introspection, so it's a much less painful
change.
>
> > Further, we cannot really change this (the public API
> > signature) anyway. One of the premises of Commons packages is that we
> > will take special care to maintain backwards compatibility, and
> > arbitrarily removing a public method doesn't count as maintaining :-).
>
> Yes, you are right. But what could be done, is to change the semantics
> of the method. It would not return an array of ALL properties, it would
> only return an array of the normal and indexed ones (and perhaps the
> mapped ones).
>
> --
> gR
>
>
>
>
Craig
