Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
I agree with keeping expression evaluation separate from DynaBeans. Not only does this provide for consistency (what method on a standard JavaBean knows how to interpret one.two[3].four(5) :-), but different applications might want to use different expression language syntaxes -- and baking a particular one into the beans themselves would really hamper this. Craig On Thu, 18 Apr 2002, James Strachan wrote: Date: Thu, 18 Apr 2002 13:07:56 +0100 From: James Strachan [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) From: James Strachan [EMAIL PROTECTED] - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] This is what I was getting at. If DynaBeans were to become used as the main interface (instead of PropertyUtils), then DynaBeans would need to support this notation. I think DynaBeans is a great abstraction for DynaBeans and regular beans. DynaBeans can handle * regular properties via get(String name) * indexed properties via get(String name, int index); * mapped properties via get(String name, String key); Where DynaBeans are maybe not the best abstraction right now is for complex expressions like one.two[3].four(5). Incidentally, there's an expression language I refer to as JEL (Java Expression Language) - I'm hoping the name catches on like JSTL did ;-). Its used in JSTL, will be native in JSP soon and I think JSF uses it too. Its quite similar to a superset of the expression language currently supported by beanutils. Right now it exists in the JSTL reference implementation over at jakarta-taglibs in the 'standard' taglib and hopefully its gonna move over to jakarta commons sometime soon. When JEL moves over here, we're gonna have a seperate commons component for parsing and evaluating complex expressions on beans, Maps, Lists, arrays (and hopefully DynaBeans too). So maybe its a good idea to consider expression languages as being logically seperate from an 'introspection wrapper'. i.e. that DynaBeans can be used as a great wrapper around introspection while supporting new features like mapped properties and DynaBeans themselves too and that expression languages should be used seperately, either via the API in beanutils right now or the JEL which will arrive here later. Does that sound a reasonable strategy? James _ 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Yes, keeping it separate makes sense to me. Let me explain my interest in this area. At joda.org (and for my day job) I have been developing classes to manage domain models. Part of this work has involved defining classes that provide bean meta data, similar to DynaClass and PropertyDescriptor and bean property access. Also built is code to query the object model using XPath backed by Jaxen. On my todo list was an implementation of the JEL syntax. I hadn't decided if that should be done as a plugin to Jaxen, or from scratch. So two things are in my mind. 1) Can I reuse the (forthcoming) JEL implementation from commons? 2) Could the joda work potentially form the basis for the new commons component that James describes? Stephen From: Craig R. McClanahan [EMAIL PROTECTED] I agree with keeping expression evaluation separate from DynaBeans. Not only does this provide for consistency (what method on a standard JavaBean knows how to interpret one.two[3].four(5) :-), but different applications might want to use different expression language syntaxes -- and baking a particular one into the beans themselves would really hamper this. Craig On Thu, 18 Apr 2002, James Strachan wrote: Date: Thu, 18 Apr 2002 13:07:56 +0100 From: James Strachan [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) From: James Strachan [EMAIL PROTECTED] - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] This is what I was getting at. If DynaBeans were to become used as the main interface (instead of PropertyUtils), then DynaBeans would need to support this notation. I think DynaBeans is a great abstraction for DynaBeans and regular beans. DynaBeans can handle * regular properties via get(String name) * indexed properties via get(String name, int index); * mapped properties via get(String name, String key); Where DynaBeans are maybe not the best abstraction right now is for complex expressions like one.two[3].four(5). Incidentally, there's an expression language I refer to as JEL (Java Expression Language) - I'm hoping the name catches on like JSTL did ;-). Its used in JSTL, will be native in JSP soon and I think JSF uses it too. Its quite similar to a superset of the expression language currently supported by beanutils. Right now it exists in the JSTL reference implementation over at jakarta-taglibs in the 'standard' taglib and hopefully its gonna move over to jakarta commons sometime soon. When JEL moves over here, we're gonna have a seperate commons component for parsing and evaluating complex expressions on beans, Maps, Lists, arrays (and hopefully DynaBeans too). So maybe its a good idea to consider expression languages as being logically seperate from an 'introspection wrapper'. i.e. that DynaBeans can be used as a great wrapper around introspection while supporting new features like mapped properties and DynaBeans themselves too and that expression languages should be used seperately, either via the API in beanutils right now or the JEL which will arrive here later. Does that sound a reasonable strategy? James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
On Thu, 18 Apr 2002, Stephen Colebourne wrote: Date: Thu, 18 Apr 2002 21:27:09 +0100 From: Stephen Colebourne [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) Yes, keeping it separate makes sense to me. Let me explain my interest in this area. At joda.org (and for my day job) I have been developing classes to manage domain models. Part of this work has involved defining classes that provide bean meta data, similar to DynaClass and PropertyDescriptor and bean property access. Also built is code to query the object model using XPath backed by Jaxen. On my todo list was an implementation of the JEL syntax. I hadn't decided if that should be done as a plugin to Jaxen, or from scratch. So two things are in my mind. 1) Can I reuse the (forthcoming) JEL implementation from commons? That would be the whole point of moving it to commons. The expression evaluation code we are currently talking about moving here is embedded inside the JSTL implementation (directory standard in jakarta-taglibs), but is easily separable. 2) Could the joda work potentially form the basis for the new commons component that James describes? One of the keys for the migrated expression language code will be to faithfully implement the expression language required by JSTL and JSP 1.3 (and, ultimately, other things like JavaServer Faces). The current code has a head start, in that it already implements that syntax and semantics, but that also creates a constraint to remain compatible. It might well be that a separate commons component implementing a different expression language syntax would also be useful (the Commons charter specifically allows for multiple approaches to the same problem domain), although I'd personally prefer to see people standardize on one such language. Using XPath to access trees of JavaBeans is currently available in the commons-jxpath package -- it might be worth taking a look to see if collaborations are possible there as well. Stephen Craig From: Craig R. McClanahan [EMAIL PROTECTED] I agree with keeping expression evaluation separate from DynaBeans. Not only does this provide for consistency (what method on a standard JavaBean knows how to interpret one.two[3].four(5) :-), but different applications might want to use different expression language syntaxes -- and baking a particular one into the beans themselves would really hamper this. Craig On Thu, 18 Apr 2002, James Strachan wrote: Date: Thu, 18 Apr 2002 13:07:56 +0100 From: James Strachan [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) From: James Strachan [EMAIL PROTECTED] - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] This is what I was getting at. If DynaBeans were to become used as the main interface (instead of PropertyUtils), then DynaBeans would need to support this notation. I think DynaBeans is a great abstraction for DynaBeans and regular beans. DynaBeans can handle * regular properties via get(String name) * indexed properties via get(String name, int index); * mapped properties via get(String name, String key); Where DynaBeans are maybe not the best abstraction right now is for complex expressions like one.two[3].four(5). Incidentally, there's an expression language I refer to as JEL (Java Expression Language) - I'm hoping the name catches on like JSTL did ;-). Its used in JSTL, will be native in JSP soon and I think JSF uses it too. Its quite similar to a superset of the expression language currently supported by beanutils. Right now it exists in the JSTL reference implementation over at jakarta-taglibs in the 'standard' taglib and hopefully its gonna move over to jakarta commons sometime soon. When JEL moves over here, we're gonna have a seperate commons component for parsing and evaluating complex expressions on beans, Maps, Lists, arrays (and hopefully DynaBeans too). So maybe its a good idea to consider expression languages as being logically seperate from an 'introspection wrapper'. i.e. that DynaBeans can be used as a great wrapper around introspection while supporting new features like mapped properties and DynaBeans themselves too and that expression languages should be used seperately, either via the API in beanutils right now or the JEL which will arrive here later. Does that sound a reasonable strategy? James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
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
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] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
What's the MappedPropertyDescriptor class in the package then?... Seems to work too. For Object getMyProperty(String key). The getPropertyDescriptor method seems to find it okay. Or is something else needed?... Only thing which made it an issue before was the other variety java.util.Map getMyProperty() but then again, the IndexedPropertyDescriptor doesn't like that version (Get the whole collection, then use the index on it) of property methods either. Arron. Craig R. McClanahan wrote: On Fri, 12 Apr 2002, Matt Johnson wrote: Date: Fri, 12 Apr 2002 10:45:39 +1000 From: Matt Johnson [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) [apologies - package name now inserted in subject] Folks, Is anyone working towards fixing PropertyUtils to work with DynaBeans (ie, where all the FIXME tags are)? What's the status (if any), and will this be included in 1.1 final? If this is currently in limbo, has anyone already patched this privately (before I go and diy)? Patches to these areas would be welcomed! Some of them are going to get really interesting, though, because the standard PropertyDescriptor doesn't really contemplate such a thing as a mapped property. Thanks, Matt J. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
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? What's the MappedPropertyDescriptor class in the package then?... Seems to work too. For Object getMyProperty(String key). The getPropertyDescriptor method seems to find it okay. Or is something else needed?... Only thing which made it an issue before was the other variety java.util.Map getMyProperty() but then again, the IndexedPropertyDescriptor doesn't like that version (Get the whole collection, then use the index on it) of property methods either. Arron. Craig R. McClanahan wrote: On Fri, 12 Apr 2002, Matt Johnson wrote: Date: Fri, 12 Apr 2002 10:45:39 +1000 From: Matt Johnson [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) [apologies - package name now inserted in subject] Folks, Is anyone working towards fixing PropertyUtils to work with DynaBeans (ie, where all the FIXME tags are)? What's the status (if any), and will this be included in 1.1 final? If this is currently in limbo, has anyone already patched this privately (before I go and diy)? Patches to these areas would be welcomed! Some of them are going to get really interesting, though, because the standard PropertyDescriptor doesn't really contemplate such a thing as a mapped property. Thanks, Matt J. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
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]
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
On Fri, 12 Apr 2002, Matt Johnson wrote: Date: Fri, 12 Apr 2002 10:45:39 +1000 From: Matt Johnson [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors) [apologies - package name now inserted in subject] Folks, Is anyone working towards fixing PropertyUtils to work with DynaBeans (ie, where all the FIXME tags are)? What's the status (if any), and will this be included in 1.1 final? If this is currently in limbo, has anyone already patched this privately (before I go and diy)? Patches to these areas would be welcomed! Some of them are going to get really interesting, though, because the standard PropertyDescriptor doesn't really contemplate such a thing as a mapped property. Thanks, Matt J. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
