commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Date Sat, 13 Apr 2002 13:42:05 GMT
What I am really getting at is whether it would be worth having the ability
in beanutils to replace Introspector. What I have in mind (borrowed from a
James Strachan idea)  is a new class, lets say  IntrospectUtils  that can be
used instead of Introspector. The only method of relevance is
getBeanInfo(Class). By default, IntrospectUtils would simply call on to
Introspector.

Then, we would define a new beanutils interface  BeanInfoProvider  that has
a getBeanInfo(Class) method. Instances of BeanInfoProvider could be
registered with IntrospectUtils. Calling getBeanInfo() on IntrospectUtils
would then call each registered provider in turn. If the provider returned
BeanInfo then that would be returned, else Introspector would be used.

An implementation of BeanInfoProvider could then be added for DynaBeans.
This could enable parts of PropertyUtils to be simplified, treating
DynaBeans the same as regular beans. (It would also allow the joda project
to interoperate with PropertyUtils :). There could even be a full
reimplementation of Introspector for normal beans to create and return
MappedPDs when it spots them. (and ListPDs as well...).

I guess this comes down in part to the goals of beanutils. If it is strictly
following the beans spec then this isn't appropriate. But then with MappedPD
and DynaBeans IMHO the project has already strayed beyond the original
concept of reflection helper methods.

Stephen

> From what I understand, the property descriptor really handles the
> straight invocation of a bean property, not getting a hold of a
> collection and using it. For example, the IndexedPropertyDescriptor
> won't get back the Object[] and then get the object from the index, it
> only takes the "Object getMyProperty(index)" style property methods.
>
> If you look at the indexed part of PropertyUtils, handling the Object[]
> is the special case outside of the descriptor. Through this we're also
> getting an item from a java.util.List implementation.
>
> Similar to all that is the MappedPropertyDescriptor.
>
> PropertyUtils/BeanUtils was apparently meant to be an implementation of
> the Bean spec (though I don't see mapped properties in the bean spec :),
> and to carry it out seems that these collection type uses need to be
> manually handled. Use PropertyUtils and you'll get at your Lists.
>
> Arron.
>
> Stephen Colebourne wrote:
>
> >I've just spent the evening trying to figure out the property descriptor
> >classes myself. For the joda project I wanted to return a BeanInfo
> >specifying a description of the bean. But it seems to be a bit tricky.
> >
> >PropertyDescriptor is OK for my needs (just about)
> >IndexedPropertyDesciptor is not much use as it only covers arrays, not
Lists
> >MappedPropertyDescriptor seems to be of limited use. It is picked up from
> >BeanInfo, but does not include the Map getXxxMap() type method as Arron
> >noted.
> >
> >Nothing really handles Lists, and I also noted that DynaBeans don't use
> >PropertyDescriptors.
> >
> >One solution would be for beanutils to have a ListPropertyDescriptor that
> >copes with getXxxList() and getXxx(int). Plus extending
> >MappedPropertyDescriptor to cover getXxxMap().
> >
> >This all seems hard work however. The beans spec is pretty outdated these
> >days (thats why I started joda really). My question is whether these
> >extended (ie. java.beans) PropertyDescriptor classes really are that
> >useful - can they really be used as general purpose classes without
writing
> >a full replacement to java.beans.Introspector?
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message