commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rey Francois <Francois....@capco.com>
Subject RE: [beanutils][PATCH] PropertyUtils and indexedProperties
Date Tue, 27 Nov 2001 08:58:33 GMT
What you are suggesting means creating a new kind of property. In the JDK,
you'll find the classes PropertyDescriptor and IndexedPropertyDescriptor
which represent respectively regular and indexed properties. In the commons
BeanUtils, you will find a MappedPropertyDescriptor that represent the
properties stored in a Map. Your suggestion means creating a new
PropertyDescriptor class, for example ListPropertyDescriptor.

However there are a few hurdles. First there is the possibility of ambiguity
with indexed properties. While 'property[1]' necessarily means in the
current implementation an indexed property, introducing list properties can
make this notation ambiguous: is it list or indexed? Somehow we have to
define rules that allows a clear distinction between the two, even if we use
the same notation. Resolving this ambiguity needs to take into account how
the JavaBean spec is actually implemented in the JDK, meaning it has to
respect the requirements for an indexed property to be recognized as such by
IndexedPropertyDescriptor.

Secondly the support for an 'add' method as a setter introduces another
ambiguity: there is now two kinds of single-value setter methods, one that
takes a value and an index, and a second one that just takes a value. Which
one to use in which situation and through which protocol? While the notation
'property[1]' clearly means using the indexed setter, we will need to find
another convention for using the 'add' method.

I like your suggestion, I think it can be implemented, but we need to think
this through very well because there are important dependencies in the way
things are already implemented, both in the JDK and in BeanUtils, and of
course backward compatibility must be maintained. Somehow I wish that these
new kinds of properties could be additions to the JavaBeans spec. itself,
because in the end all we are doing is extending the concept of what is a
property. The JavaBeans spec is old an has not changed for a long time.
Personally I would love to see a JSR that would extend it in order to
support new property types...

Fr.

-----Original Message-----
From: Elli Albek [mailto:EAlbek@altoweb.com]
Sent: 27 November 2001 07:22
To: Jakarta Commons Developers List
Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties


The beans specification handles only arrays, but do we care?
The BeanUtils package is loosely binded anyway ("foo.bar.scott.tiger" makes
no assumption on the classes).
it is possible that the methods in beanUtils will check for every array
getter if the type of the property is an array or a java.util.List, and
handle it appropriately. Since everything is loosely binded, this should not
cause a major problem (well, as long as you are trying to get values and not
set them).

Creating new values in the array is a different story. 
With arrays, you don't know the size, so you might have to clone an array if
you are trying to insert an object in an index that is bigger than the array
size.
This is why we have collections :-)
But with collections, you don't know the type of object in the list.

A solution is to modify your beans (and BeanUtils) to have a method for
adding an item to an indexed property.
Some bean code generators do that automatically.

Example:

instead of 
class foo {
  Bar[] getBars();
  void setBars(Bar[] bars);
}
Your bean might contain:

class foo{
  List getBars();
 
  /** An example implementation */
  void addBars(Bar newBar){
     if (bars == null) 
        bars = new ArrayList();
     bars.add(newBar);
  }
 
  void setBars(Bar bar, index i);
 
  Bar getBars(int index);
}

Not the cleanest solution in the world, but it is a must for some APIs that
require collections.

Notice that there is no setBars(List bars) method. In the common case you
will get the list and modify it, but not create a new list yourself and set
it. This is I guess a user preference.

E

-----Original Message-----
From: Rey Francois [mailto:Francois.Rey@capco.com]
Sent: Wednesday, November 07, 2001 2:31 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties


You can still use your patch in your application. You just have to be aware
of the limitation, which I think is substantial though. The advantages I see
in the spec of using arrays is that it is a "basic" type allowing type
checking, while collections like List are not type safe. Introducing the
flexibility to use collections in the spec will of course make it impossible
to have type safety, but also it would make life harder for those using non
standard collections like the one in Jakarta Commons and JGL.

By the way, this issue of type-safety against flexibility also appears for
mapped properties. In this case, the non-keyed accessors have to return a
type which can only be a Map interface if we want to be the most standard as
possible, but of course Map are not type safe. Note that the current
implementation is not supporting non-keyed accessors, but it is likely that
it will at some point, using the Map interface.

Fr.

-----Original Message-----
From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com]
Sent: 07 November 2001 11:06
To: Jakarta Commons Developers List
Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties


Yes, I read that also, but I also thought that that paragraph didn't say
it was exhaustive.

Reading it again, I think it implicitly states that though.

So forget the patch, you've proven you're right ;-)


tomK, who should really buy a JavaBeans book (or read the specs anyway)


> -----Original Message-----
> From: Rey Francois [mailto:Francois.Rey@capco.com] 
> Sent: woensdag 7 november 2001 10:38
> To: 'Jakarta Commons Developers List'
> Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties
> 
> 
> Well, my understanding of the JavaBean spec is that the only 
> type allowed
> for non-indexed getter/setter of an indexed property is an 
> array. Reading
> the spec 1.01, section 7.2, it does not specify any other type. This
> conforms to the JDK 1.3.1 code i've looked at...
> Fr.
> 
> -----Original Message-----
> From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com]
> Sent: 07 November 2001 10:37
> To: Jakarta Commons Developers List
> Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties
> 
> 
> Of course I tried it, but only on Struts (not on a generic javabeans
> interpreter like an IDE). And it works for a non indexed 
> getter based on
> List.
> 
> Maybe I got the whole JavaBeans story wrong. However, if what you
> describe is the case, then the JavaBeans mechanism seems even less
> powerful than I thought. Seems a pity to me.
> 
> Is anybody sure that (s)he understands the JavaBeans spec, and whether
> this patch is applicable?
> 
> Thanks,
> tomK
> 
> 
> 
> > -----Original Message-----
> > From: Rey Francois [mailto:Francois.Rey@capco.com] 
> > Sent: woensdag 7 november 2001 10:22
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties
> > 
> > 
> > Have you actually tried this code?
> > I've only *briefly* looked into the JDK and BeanUtils code, 
> > so I'm not 100%
> > sure of this, but it seems to me that your patch may work 
> > when your property
> > only has non indexed getter/setter based on List, but should 
> > fail if your
> > property also has indexed getter/setter. In the latter case, 
> > I would expect
> > the JDK IndexedPropertyDescriptor class to throw an
> > IntrospectionException("type mismatch between indexed and 
> non-indexed
> > methods"). Check the source of
> > IndexedPropertyDescriptor.findIndexedPropertyType().
> > 
> > Again, I'm not 100% sure, I would need to test this but I 
> > don't have time at
> > present...
> > 
> > Fr.
> > 
> > -----Original Message-----
> > From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com]
> > Sent: 07 November 2001 09:55
> > To: Jakarta Commons Developers List
> > Subject: [beanutils][PATCH] PropertyUtils and indexedProperties
> > 
> > 
> > Hi all,
> > 
> > I found a glitch in the PropertyUtils: you can only get an
> > indexedProperty if its container is an array. But a 
> java.util.List is
> > also indexed. So it would be logical to be able to get an 
> element of a
> > List also as an indexedProperty.
> > 
> > Hence the patch attached.
> > 
> > Hope you enjoy it,
> > 
> > tomK
> > **************************************************************
> > **********
> > The information in this email is confidential and is intended solely
> > for the addressee(s).
> > Access to this email by anyone else is unauthorised. If you are not
> > an intended recipient, please notify the sender of this email 
> > immediately. You should not copy, use or disseminate the 
> > information contained in the email.
> > Any views expressed in this message are those of the individual
> > sender, except where the sender specifically states them to be
> > the views of Capco.
> > 
> http://www.capco.com
> **************************************************************
> *********
> 
> 
> --
> 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>
> **************************************************************
> **********
> The information in this email is confidential and is intended solely
> for the addressee(s).
> Access to this email by anyone else is unauthorised. If you are not
> an intended recipient, please notify the sender of this email 
> immediately. You should not copy, use or disseminate the 
> information contained in the email.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Capco.
> 
http://www.capco.com
***********************************************************************


--
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>
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email 
immediately. You should not copy, use or disseminate the 
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***********************************************************************


--
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>
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email 
immediately. You should not copy, use or disseminate the 
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***********************************************************************


--
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