commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [BeanUtils] - Extensions for dotted queries...
Date Wed, 23 Apr 2003 20:39:20 GMT

On Wednesday, April 23, 2003, at 07:51 PM, Rune Johannesen wrote:

> Hi again, Robert!
>
> Just a few comments from my side related to the issues you raised.
>
>
> 1) Naming convention
>
> I called the class "Object"-Utils because it allows you to query 
> "container"
> like data structures (i.e. arrays, List objects, Map objects and
> Collections) as result objects in addition to the standard bean 
> properties.
> Per definition Map, List and array objects are not a beans, thus "object"
> .
>
> I realise that the naming of the class is a bit unfortunate, especially
> since the Commons-Lang has a class:	
>
> 	org.apache.commons.lang.ObjectUtils
>
> Therefore we might consider renaming it (what about BeanObjectUtils?) or
> perhaps include the features as dedicated methods in the existing 
> BeanUtils
> class. I don't have any strong opinions about how it is done - the easiest
> way to contribute with the changes was to simply add new classes.

(as is often the case) henri's suggestion seems like the way to go (if we 
go for a separate class). BeanContainerUtils sounds pretty good :)

> 2) Scope
>
> In my opinion this would be within the scope of the BeanUtils project 
> since
> the aim is to be able to continue querying the objects returned from bean
> properties, even though the return objects themselves aren't (necessarily)
> beans. The existing nested properties only allows you to continue the 
> query
> if the returning object is a bean. My intent was not primarily to add
> support of non-beans, but to to extend the existing beans property 
> querying
> system to allow queries in arbitrary return objects in a consistent 
> fashion.

my principle worry was that either the ObjectUtils class was badly named 
or have a contract so vague that it would be out of scope.

> 3) Backwards compatibility
>
> These changes should be bulletproof with respect to backwards 
> compatibility.
> None of the existing classes are changed, and as long as the class names 
> and
> method signatures of the existing classes aren't modified we should be 
> fine.
> Adding classes or distinct method signatures I don't regard problematic.

what i wondered is whether the existing nested property syntax could be 
extended in a backwards compatible manner to include your proposed 
improvements.

> 4) DynaBean support
>
> As I am not experienced with the usage of the DynaXXX myself I would
> appreciate if someone more familiar with that concept takes on the task to
> support it. If that doesn't happen I am happy to do it.

dynabeans are quite funky and they are probably worth taking the 
half-an-hour or so that it'll take to familarize yourself with them even 
if someone else volunteers to provide support.

> Cheers,
>
> Rune Toalango
>
> PS! The conclusion after a discussion with P. Hammant was to withdraw the
> NestedObjectUtils (too specialised behaviour/use case), but to submit the
> ObjecUtils class

one thing strikes me is that if these queries languages can't be supported 
together in a backwards compatible manner, maybe this is something that 
would benefit from a pluggable strategy interface rather than simply 
having different methods. then you could easily have the more advanced 
implementation extending the more basic one.

this would mean that all code building on getNestedProperty could change 
bean query language implementations without recompilation. this would 
allow (for example) as JXPath plugin which would be pretty cool.

- robert


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