commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Gilde" <>
Subject RE: Jelly and a new beta release
Date Tue, 14 Sep 2004 03:53:29 GMT
I agree about JEXL being an alternative BQL.

But, Beanutils also gives us dynabeans. In theory, dynabeans give us an
implementation for two types of tags: tags that take all their properties
through setXXXX and getXXXX and tags that are more dynamic.

The beanutils package detects dynabeans and handles them just like regular
beans. In theory. Apparently, something about dynabeans didn't work in an
earlier beanutils because jelly doesn't use dynabeans quite right. If it
did, the code would be lots cleaner. I'm actually filing this as an issue in
jira now.

Now, the facts are that a) we don't use dynabeans exactly correctly and b)
we could probably squeeze a little more speed out of dynamic tags if we
directly use a Map of properties rather than dynabeans. 

Now to add a twist: beanutils will also query the tag (either dyna or
regular bean) and give you a list of all the bean properties, and hence all
the possible XML attributes, for documentation purposes. This *could* be a
pre-built path to auto-documenting dynamic tag libraries like Swing. The
only part that's not handled by beanutils is the part about attaching a text
description to properties found from each tag.

So... to summarize. We could easily replace beanutils/BQL with JEXL if we're
willing to give up dynabeans. Giving up dynabeans would probably allow for a
fairly small performance increase when compiling all tags and when running
dynamic tags. The question is, what would we use instead of dynabeans?

-----Original Message-----
From: robert burrell donkin [] 
Sent: Monday, September 13, 2004 4:32 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release

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:

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

View raw message