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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ************************************************************************** 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
