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 BQL.)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
