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] - Some thoughts on query languages including beans
Date Fri, 09 May 2003 16:24:30 GMT
i think that i agree in principal with a lot of this. the AccessLanguage 
is pretty much the strategy interface which i advocated plugging into 
PropertyUtils so it's the way that i'd prefer to support alternative query 
languages.

i'm not sure that you've got the dynabeans stuff correct, though. 
dynabeans is an additional reflection alternative technology. this means 
that it acts at conceptually a lower level (like clazz) than the query 
language stuff. if you have the energy take a look at clazz in the sandbox 
which operates at the same conceptual level as dynabeans.

the difficult bit is coming up with the right structure for pluggable 
queries and pluggable reflection but that can be thought about later :)

- robert

On Tuesday, May 6, 2003, at 11:47 AM, Rune Johannesen wrote:

> Folks,
>
> I've spent some time looking at the options for querying nested bean
> properties. Here are some of the findings:
>
>  * The existing nested querying in BeanUtils (although limited to bean
> properties only)
>  * The OGNL project (Object-Graph Navigation Language, see
> http://www.ognl.org/), also allowing queries in pure methods
> (non-bean-property methods)
>  * The technique for purely dotted queries (also allowing queries in
> arbitrary container-like structures)
>  * The JXPath project (http://jakarta.apache.org/commons/jxpath/)
>
> The evolution of different standards on this arena challenges the 
> BeanUtils
> project and its modularity in several ways;
>
>  * the classes that abstracts the clients from the java.beans package are
> highly reusable (the stuff that covers the details like indexed 
> properties,
> mapped properties, array properties etc.)
>  * the DynaBean and DynaClass appears to be quite proprietary to the
> BeanUtils project - what about making it an optional extension / plugin?
>  * a clean separation between interface and implementaion would allow more
> reuse and flexibility
>  * the core bean properties utilities and the query languages (access
> syntaxes) must be separated, i.e. the same data structure could be queried
> using different query languages
>
> Here are some lines of pseudo-code to examplify the high-level
> interface/implementation separation:
>
> 	public interface AccessLanguage {
> 	    Object get(String pObject, String pQuery);
> 	    void set(String pObject, String pQuery, Object pValue);
> 	}
>
> 	public class JXPathSyntax implements AccessLanguage {
> 	    ...
> 	}
>
> 	public class DottedSyntax implements AccessLanguage {
> 	    ...
> 	}
>
> 	public class DynaSupportSyntax implements AccessLanguage {
> 	    ...
> 	}
>
> This would allow a variety of pluggable modules to co-exist in the 
> BeanUtils
> project and eliminate some of the difficulties the project faces in terms 
> of
> scope definition, I think.
>
>
>
> Cheers,
>
> Rune Toalango
>
> ---------------------------------------------------------------------
> 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