commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Jelly and a new beta release
Date Mon, 13 Sep 2004 21:32:28 GMT
On 12 Sep 2004, at 21:27, Hans Gilde wrote:

> When you say "allowing tag libraries to declare bindings", do you mean 
> Java
> tag libs declaring Java constructs, Java tag libs declaring XDoclet
> constructs or a separate descriptor for each tag lib? Or a combination 
> of
> the above?

i have no good, clear preferences about implementation...

> On the bean query language thing:
> A construct like ${bean.array[2].property} would use JEXL, which might 
> use
> BQL for all I know. But Jelly would not use BQL directly in this case.

i thought that would be the case.

(on the subject of nomenclacture, i'd describe both JEXL and beanutils 
as embedding bean query languages as opposed to beanutils having the 

> When converting XML attributes to bean properties, Jelly currently uses
> BeanUtils.populate. Now, BeanUtils recommends using copyProperties 
> instead
> of populate. I was thinking of changing to copyProperties recently, 
> until I
> noticed a somewhat odd side effect of populate: If you declare an XML
> attribute a.b="foo", the string "a.b" will be passed to populate as the
> property name. populate will use BQL, and this single XML property will
> result in bean.getA().setB("foo"). So, in this case, BQL is used. I 
> don't
> know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
> complain. I also don't know if we want an XML attribute a.b to resolve 
> to
> getA().setB() but... it makes the whole thing a little more 
> complicated.

populate is a specialization aimed at processing HTTP requests. i 
suspect that james chose this because xml<->object is also 
text<->object. choosing just one system does have limitations.

you're example is a good illustration of the absence of a general 
solution. in some cases, a.b would be best interpreted as a bean query 
language phrase and in other cases, it would be better passed without 
conversion to the bean. i suspect that one size doesn't fit all and 
that it might be better for conversions to be specified by each tag 
library (possible using beanutils as a default). JEXL should provide 
sufficient query language glue.

> Also, the "set" tag (sets a bean property on a parent bean tag) relies 
> on
> BeanUtils to resolve the property name and BeanUtils uses BQL, which we
> definitely want.

i don't think that anyone objects to beanutils tag libs: it's the core 
embedding that's more arguable.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message