commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rune Johannesen <rune.johanne...@digitalrum.com>
Subject RE: [BeanUtils] - Extensions for dotted queries...
Date Fri, 28 Mar 2003 18:00:36 GMT
Yes (of course), my point was, however, that the level of abstraction in the
dotted queries is higher. I.e. you can change the underlying implementation
of classes/properties without necessarily having to change the queries
elsewhere in the system, and the end user (the one writing the queries)
don't have to care about the data structure (irrelevant wether it is an
ordinary bean property or a value in a map with a String as a key etc. I
consider this to be an important issue because with String-based queries
(typically used in page-based front-ends) the major challenge is to manage
changes to the underlying code transparently with respect to the client page
during refactoring.


- Rune

-----Original Message-----
From: Hope, Matthew [mailto:Matthew.Hope@capitalone.com] 
Sent: 28 March 2003 14:52
To: 'Jakarta Commons Developers List'
Subject: RE: [BeanUtils] - Extensions for dotted queries...


You are aware that the following two methods could not coexist in the same
class?

	/**
	 * 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();

(and even though you could mix overloaded methods with different return
types I would view it as dangerous code to have hanging around)

Matt 

-----Original Message-----
From: Rune Johannesen [mailto:rune.johannesen@digitalrum.com] 
Sent: 28 March 2003 14:04
To: 'Jakarta Commons Developers List'
Subject: RE: [BeanUtils] - Extensions for dotted queries...


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 "phone.work" 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.

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").

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



Cheers,

Rune

-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk] 
Sent: 27 March 2003 20:13
To: Jakarta Commons Developers List
Subject: Re: [BeanUtils] - Extensions for dotted queries...


hi Rune

(maybe i'm a little confused but...)

could you explain to me the differences between you code and the existing 
support for nested property access?

- robert

On Thursday, March 20, 2003, at 03:00 PM, Rune Toalango Johannesen wrote:

> Due to problems getting the previous email with some code through
> paranoid firewalls I try again here... ;)
>
> The original email:
>
> [BeanUtils] - Extensions for dotted queries in composite data 
> structures
>
> Guys,
>
> Attached you find some classes that extends the functionality of the
> existing BeanUtils package;
>
>         ObjectUtils
>
> and
>
>         NestedObjectUtils
>
> The purpose of this extension is to allow bean property queries not 
> only on pure beans, but in composite data structures that might 
> involve maps, lists, arrays and collections in addition to the 
> traditional beans.
>
> The ObjectUtils lets you resolve dotted queries like this;
>
>         String text = (String) ObjectUtils.get(namespace,
> "session.products.0.children.2.displayText");
>
> as opposed to
>
>         String text = (String) ((List) ((Catalog) 
> namespace.get("session" )).getProducts()).get(0)............
>
> The NestedObjectUtils lets you do the same, but allows nested queries
> like;
>
>         
> "session.products.0.children.{request.parameter.childNumber}.displayTe
> xt"
>
> The NestedObjectUtils depends on the Commons-Lang
> (org.apache.commons.lang.StringUtils) in addition to the existing 
> BeanUtils dependencies.
>
> I've javadoc'ed the code and provided some unit tests... Let me know 
> what you think - should this be included in the BeanUtils package in 
> some future release? What about extending it to support the DynaBean 
> concept? What about extending the query language in the BeanUtils 
> package in general to support both traditional () and [] delimiters in 
> addition to the uniformed dot - as it is used in these classes?
>
>
>
> <<beanutils-extension.zip>>
>
>
>
> Cheers,
>
> Rune 
> ______________________________________________________________________
> ________
> Sie haben mehr zu sagen als in eine SMS passt? Mit WEB.DE FreeMail ist 
> das jetzt kein Problem mehr! 
> http://freemail.web.de/features/?mc=021182
>  ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message