Hi Stephen I did think a standard wrapper around the Introspector would be a good idea, especially because the standard introspection mechanism cannot support DynaBeans, since the Introspector just takes a Class rather than the instance, and its the instance data of a DynaBean (its DynaClass) which defines its properties etc.
Though I guess the static methods of PropertyUtils actually are this wrapper. e.g. PropertyUtils.getPropertyDescriptors(bean); PropertyUtils.getMappedPropertyDescriptors(bean); Also DynaBeans right now can't support beans PropertyDescriptors, presumably because its not possible to implement read & write Methods. Unfortunately Method is final so we couldn't create a method proxy that the getter would call DynaBean.get( "someName" ) and similar for the setter method. So it wouldn't be possible to make DynaBeans act like regular beans. (Shame!). Though maybe another idea is to treat everything as a DynaBean. Any regular bean can be wrapped pretty easily as a DynaBean. e.g. Object bean = ...; DynaBean dynaBean = new WrapDynaBean( bean ); So maybe DyanBean could actually become the wrapper around the introspector? This approach would then supports beans, DynaBeans, mapped properties and so forth in a simple consistent manner. Also the DynaBean / DynaClass is alot easier than working from the Introspector directly, no need to mess with arrays of PropertyDescriptors et al. WrapDynaClass maintains a Map of PropertyDescriptors so its an efficient way of working with beans. Also WrapDynaClass instances are cached so all in all the approach of using DynaBeans all the time as a bean/Introspector replacement seems like a good idea. So if you're not being typesafe, using DynaBeans seems like the way to go. DynaBeans rock ;-) James ----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Saturday, April 13, 2002 2:42 PM Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) > 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:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] rg> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
