On Tue, 21 Aug 2001, Gregor Rayman wrote:
> "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
> > I'll look at integrating both indexed-setter and keyed property support
> > into the jakarta-commons beanutils code. Fair warning -- I'm gonig to
> > want to see JUnit tests too before a new release :-).
>
> :-) Of course.
>
> > > Also I am not so happy with the structure of PropertyUtils as is is now.
> > > E.g. the method getPropertyDescriptors(Object bean) should not be
> > > public if dynamic properties are allowed, since we cannot retrieve
> > > a complete list of all properties and so it will only return the
> > > standard and integer indexed properties, with a bit of effort it could
> > > return the string keyed ones, but I've no idea, how it could return the
> > > list of dynamic ones.
> > >
> >
> > In order for BeanUtils.populate() to work according to it's Javadocs, it
> > needs to have a way to ask for the list of valid properties that are
> > supported by the bean. This functionality is absolutely critical in
> > Struts (it's how request parameters get copied into an ActionForm
> > bean). IMHO, any implementation of dynamic properties needs to support a
> > way that the valid properties can be enumerated.
>
> 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.
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 :-).
> --
> gR
>
>
>
Craig
