commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [BeanUtils] - Extensions for dotted queries...
Date Wed, 23 Apr 2003 15:12:43 GMT
hi rune

sorry for taking so long to get back to you.

On Friday, March 28, 2003, at 02:03 PM, Rune Johannesen wrote:

> Hi Robert,
> It's a good question. I'll try to explain by an example:
> If you have a method signature for an indexed property like this:
> 	String getName(int nameIndex);
> you can use
> 	BeanUtils.getProperty(theObject, "name[1]");
> But if the method signature looks like this;
> 	String[] getName();
> you are not able to query the structure anymore by means of the existing
> getNestedPropery method(s).
> The ObjectUtils continues to query the resulting object as long as there 
> are
> more dot-separated tokens left in the key, regardless of the object type
> returned (it can be a standard bean, a List, an Array, a Map, or even a
> Collection of String objects).
> Another thing is that the query language of ObjectUtils is more abstract
> than the existing BeanUtils queries, using [] and () and ".". Given two
> method signatures;
> 	/**
> 	 * A mapped property.
> 	 */
> 	String getPhone(String phoneType);
> 	/**
> 	 * A getter for a Map that maps the phoneType to the phoneNumber,
> 	 * here represented by a String
> 	 */
> 	Map getPhone();
> 	/**
> 	 * A getter method for a Phone object (see below).
> 	 */
> 	Phone getPhone();
> 	/**
> 	 * The Phone class signature goes like this...
> 	 */
> 	public class Phone {
> 		public String getWork();
> 		public String getHome();
> 	}
> ...queries like "" and "phone.home" would be the same for all 
> the
> three examples above, whilst the existing BeanUtils queries would
> distinguish between pure properties (separated by dots) and mapped/indexed
> properties, having () and [] in addition.

ok. i think that i understand know. sounds pretty cool.

> I realize that by submitting this code I am introducing a number of 
> separate
> issues related to the existing BeanUtils package;
>    1) Should the BeanUtils project stick to the existing delimiters (using
> (), [] and dots) or be extended to support pure
>       dotted queries as well?
>    2) Should the BeanUtils support nested queries in all data structures,
> not only BEAN properties, like the code I submitted
>       does?
>    3) Should classes like ObjectUtils be adopted without supporting the
> DynaBean and DynaClass stuff?
>    4) Should the BeanUtils package be extended with ObjectUtils without 
> set
> (write) support? For the time being the class only has
>       getter methods ("read-only").

i see these questions as being related. adding a class called ObjectUtils 
gives me grave concerns about scope. if these changes are aimed at adding 
a very useful extension of the nested properties syntax, then that's in 
scope. if they are aimed at extending the idea of nested properties to 
non-beans then they are not.

by including them in a class called ObjectUtils means that i'd be inclined 
to think that they are aimed at non-beans and so are out-of-scope. your 
examples are based on beans (or at least use cases common when using beans)
  and so are in-scope.

if this is possible whilst maintaining backwards compatibility, i'd much 
prefer to extend the existing functionality than create methods in a new 
class. therefore, my answers are:

1. i'd prefer for them to be combined into a single extended system.

2. i'm not bothered if this happens as a side-effect. the change is 
probably out of scope if support of non-beans is the primary purpose.

3. a commitment to dynabean support would be necessary. i wouldn't be 
concerned if there was an initial commit without dynabean support for the 
extensions provided that someone volunteered to create a patch supporting 

4. users are going to want this implemented. i'd be happy to commit 
without support so long as someone volunteered to add this later.

> It would be interesting to hear the thoughts of the committers in the
> project related to these questions.

so would i but no one else has stepped up :)

this would be quite a major change and so i'd like to (if possible) 
achieve consensus.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message