You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Johnson <jo...@whitesmiths.com.au> on 2002/04/12 02:45:39 UTC
[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)?
Thanks,
Matt J.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Apr 2002, Stephen Colebourne wrote:
> Date: Thu, 18 Apr 2002 21:27:09 +0100
> From: Stephen Colebourne <sc...@eurobell.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> 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 <cr...@apache.org>
> > 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 <ja...@yahoo.co.uk>
> > > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > > Subject: Re: [BeanUtils] PropertyUtils and DynaBeans
> > > (getPropertyDescriptors)
> > >
> > > From: "James Strachan" <ja...@yahoo.co.uk>
> > > > ----- Original Message -----
> > > > From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> > > > > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
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 <cr...@apache.org>
> 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 <ja...@yahoo.co.uk>
> > Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: Re: [BeanUtils] PropertyUtils and DynaBeans
> > (getPropertyDescriptors)
> >
> > From: "James Strachan" <ja...@yahoo.co.uk>
> > > ----- Original Message -----
> > > From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> > > > 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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 <ja...@yahoo.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [BeanUtils] PropertyUtils and DynaBeans
> (getPropertyDescriptors)
>
> From: "James Strachan" <ja...@yahoo.co.uk>
> > ----- Original Message -----
> > From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> > > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "James Strachan" <ja...@yahoo.co.uk>
> ----- Original Message -----
> From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> > 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> From: Craig R. McClanahan <craigmcc@apache.org
> > > There
> > > doesn't seem to be any way to use the one.two[0].three(four) type
syntax
> > > however. Maybe this could be added.
> > >
> >
> > It's already there, but not in the DynaBeans themselves ... :-)
>
> 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).
I guess we could always change the get(String) and set(String, Object value)
methods of DynaBean that if the name doesn't match a well defined property
to call the PropertyUtils method to evaluate the expression? I'm not sure
I'm convinced this is a good idea yet but its certainly possible.
Though maybe for complex expressions we should use either the existing
PropertyUtils API for this or some expression API explicitly. Stuff like
these complex expressions might deserve a different API, maybe that allows
expressions to be 'compiled' first then reused many times to avoid excessive
parsing of the exception.
e.g.
Expression expression = new Expression( "one.two[3].four(5)" );
for ( int i = 0; i < 20; i++ ) {
expression.evaluate( array[i] );
}
> This could be done either by adding to the DynaBean interface:
> getNested(String)
> setNested(String, Object)
> or by changing the javadoc and implementation of get(String) and
set(String,
> Object)
>
> Any views on the better approach?
Its tempting. It would be nice to have a consistent, simple, clean API like
DynaBeans to handle all these cases.
Though I'd be happy to use DynaBeans for all 'simple' cases, bean
properties, indexed & mapped properties and DynaBeans, then use another API
for 'complex' expressions.
> > The property getter/setter methods in PropertyUtils and BeanUtils work
on
> > either standard JavaBeans or on DynaBeans, so you can use the exact same
> > property syntax on them.
>
> Thus implementation should be easy ;-)
Agreed.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
From: Craig R. McClanahan <craigmcc@apache.org
> > There
> > doesn't seem to be any way to use the one.two[0].three(four) type syntax
> > however. Maybe this could be added.
> >
>
> It's already there, but not in the DynaBeans themselves ... :-)
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.
This could be done either by adding to the DynaBean interface:
getNested(String)
setNested(String, Object)
or by changing the javadoc and implementation of get(String) and set(String,
Object)
Any views on the better approach?
> The property getter/setter methods in PropertyUtils and BeanUtils work on
> either standard JavaBeans or on DynaBeans, so you can use the exact same
> property syntax on them.
Thus implementation should be easy ;-)
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 17 Apr 2002, Stephen Colebourne wrote:
> Date: Wed, 17 Apr 2002 20:35:36 +0100
> From: Stephen Colebourne <sc...@eurobell.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [BeanUtils] PropertyUtils and DynaBeans
> (getPropertyDescriptors)
>
> > I did think a standard wrapper around the Introspector would be a good
> idea
> > ...
> > Though I guess the static methods of PropertyUtils actually are this
> wrapper.
> > 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.
>
> Hmm. The PropertyDescriptors for DynaBeans would indeed be pretty empty, so
> I guess you are right.
>
> > Though maybe another idea is to treat everything as a DynaBean.
> > 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 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 ;-)
>
> Intriguing. Overall the realatively small DynaBean interface probably does
> cover the requirements for getting and setting data from a 'bean'. There
> doesn't seem to be any way to use the one.two[0].three(four) type syntax
> however. Maybe this could be added.
>
It's already there, but not in the DynaBeans themselves ... :-)
The property getter/setter methods in PropertyUtils and BeanUtils work on
either standard JavaBeans or on DynaBeans, so you can use the exact same
property syntax on them.
> Stephen
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
> I did think a standard wrapper around the Introspector would be a good
idea
> ...
> Though I guess the static methods of PropertyUtils actually are this
wrapper.
> 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.
Hmm. The PropertyDescriptors for DynaBeans would indeed be pretty empty, so
I guess you are right.
> Though maybe another idea is to treat everything as a DynaBean.
> 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 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 ;-)
Intriguing. Overall the realatively small DynaBean interface probably does
cover the requirements for getting and setting data from a 'bean'. There
doesn't seem to be any way to use the one.two[0].three(four) type syntax
however. Maybe this could be added.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by James Strachan <ja...@yahoo.co.uk>.
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" <sc...@eurobell.co.uk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.o
rg>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Arron Bates <ar...@keyboardmonkey.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
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 <jo...@whitesmiths.com.au>
> >>Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>
> >>To: commons-dev@jakarta.apache.org
> >>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:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by Arron Bates <ar...@keyboardmonkey.com>.
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 <jo...@whitesmiths.com.au>
>>Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>To: commons-dev@jakarta.apache.org
>>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 12 Apr 2002, Matt Johnson wrote:
> Date: Fri, 12 Apr 2002 10:45:39 +1000
> From: Matt Johnson <jo...@whitesmiths.com.au>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>