|Matt Johnson||Apr 11, 2002 5:45 pm|
|Craig R. McClanahan||Apr 11, 2002 9:18 pm|
|Arron Bates||Apr 12, 2002 1:11 am|
|Stephen Colebourne||Apr 12, 2002 2:41 pm|
|Arron Bates||Apr 12, 2002 9:29 pm|
|Stephen Colebourne||Apr 13, 2002 6:41 am|
|James Strachan||Apr 15, 2002 8:40 pm|
|Stephen Colebourne||Apr 17, 2002 12:35 pm|
|Craig R. McClanahan||Apr 17, 2002 12:56 pm|
|Stephen Colebourne||Apr 17, 2002 2:23 pm|
|James Strachan||Apr 17, 2002 3:03 pm|
|James Strachan||Apr 18, 2002 5:07 am|
|Craig R. McClanahan||Apr 18, 2002 8:44 am|
|Stephen Colebourne||Apr 18, 2002 1:26 pm|
|Craig R. McClanahan||Apr 18, 2002 3:05 pm|
|Subject:||Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)|
|From:||Craig R. McClanahan (crai...@apache.org)|
|Date:||Apr 18, 2002 3:05:57 pm|
On Thu, 18 Apr 2002, Stephen Colebourne wrote:
Date: Thu, 18 Apr 2002 21:27:09 +0100 From: Stephen Colebourne <scol...@eurobell.co.uk> Reply-To: Jakarta Commons Developers List <comm...@jakarta.apache.org> To: Jakarta Commons Developers List <comm...@jakarta.apache.org> Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
Yes, keeping it separate makes sense to me. Let me explain my interest in this area. At joda.org (and for my day job) I have been developing classes to manage domain models. Part of this work has involved defining classes that provide bean meta data, similar to DynaClass and PropertyDescriptor and bean property access. Also built is code to query the object model using XPath backed by Jaxen. On my todo list was an implementation of the JEL syntax. I hadn't decided if that should be done as a plugin to Jaxen, or from scratch.
So two things are in my mind. 1) Can I reuse the (forthcoming) JEL implementation from commons?
That would be the whole point of moving it to commons. The expression evaluation code we are currently talking about moving here is embedded inside the JSTL implementation (directory "standard" in jakarta-taglibs), but is easily separable.
2) Could the joda work potentially form the basis for the new commons component that James describes?
One of the keys for the migrated expression language code will be to faithfully implement the expression language required by JSTL and JSP 1.3 (and, ultimately, other things like JavaServer Faces). The current code has a head start, in that it already implements that syntax and semantics, but that also creates a constraint to remain compatible. It might well be that a separate commons component implementing a different expression language syntax would also be useful (the Commons charter specifically allows for multiple approaches to the same problem domain), although I'd personally prefer to see people standardize on one such language.
Using XPath to access trees of JavaBeans is currently available in the commons-jxpath package -- it might be worth taking a look to see if collaborations are possible there as well.
From: Craig R. McClanahan <crai...@apache.org>
I agree with keeping expression evaluation separate from DynaBeans. Not only does this provide for consistency (what method on a standard JavaBean knows how to interpret "one.two.four(5)" :-), but different applications might want to use different expression language syntaxes -- and baking a particular one into the beans themselves would really hamper this.
On Thu, 18 Apr 2002, James Strachan wrote:
Date: Thu, 18 Apr 2002 13:07:56 +0100 From: James Strachan <jame...@yahoo.co.uk> Reply-To: Jakarta Commons Developers List <comm...@jakarta.apache.org> To: Jakarta Commons Developers List <comm...@jakarta.apache.org> Subject: Re: [BeanUtils] PropertyUtils and DynaBeans (getPropertyDescriptors)
From: "James Strachan" <jame...@yahoo.co.uk>
----- Original Message ----- From: "Stephen Colebourne" <scol...@eurobell.co.uk>
This is what I was getting at. If DynaBeans were to become used as
interface (instead of PropertyUtils), then DynaBeans would need to support this notation.
I think DynaBeans is a great abstraction for DynaBeans and regular beans. DynaBeans can handle
* regular properties via get(String name) * indexed properties via get(String name, int index); * mapped properties via get(String name, String key);
Where DynaBeans are maybe not the best abstraction right now is for complex expressions like one.two.four(5).
Incidentally, there's an expression language I refer to as JEL (Java Expression Language) - I'm hoping the name catches on like JSTL did ;-). Its used in JSTL, will be native in JSP soon and I think JSF uses it too. Its quite similar to a superset of the expression language currently supported by beanutils. Right now it exists in the JSTL reference implementation over at jakarta-taglibs in the 'standard' taglib and hopefully its gonna move over to jakarta commons sometime soon.
When JEL moves over here, we're gonna have a seperate commons component for parsing and evaluating complex expressions on beans, Maps, Lists, arrays (and hopefully DynaBeans too). So maybe its a good idea to consider expression languages as being logically seperate from an 'introspection wrapper'. i.e. that DynaBeans can be used as a great wrapper around introspection while supporting new features like mapped properties and DynaBeans themselves too and that expression languages should be used seperately, either via the API in beanutils right now or the JEL which will arrive here later.
Does that sound a reasonable strategy?