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 Sat, 11 Sep 2004 00:32:09 GMT
I like this idea. At the moment, we do have subclass-based attribute

What I really like is the automatic documentation aspect, although the
declarative part sounds good too.

Whatever the solution, we could provide a Java-only version so that tags
don't have to use the declarative syntax if they don't want to. The
Java-only version would let tags avoid a speed problem with loading mappers.

So, a set of mappers would be needed per tag library (Swing's mappings
aren't SWT's mappings) and possible per bean class. Mappers would intercept
a get/set for a specific bean property name and apply the conversion.

But, it gets more complicated because lots of libraries have methods like
setSize(int x, int y), which we want to "convert" from a single XML
attribute "size".

This sort of fits in with the idea of having an XML "config" file for every
tag library.

-----Original Message-----
From: Paul Libbrecht [] 
Sent: Friday, September 10, 2004 5:14 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release

The problem with this approach, I think, is that it could be done much 
more declaratively thus providing support for tag-documentation...

Mapping constants to integer could, for example, easily be done such.

The declarative way that I was believing to be good would be to make a 
conversion-context class, presumably in beanutils, which would be a set 
of mappers. It could be called for copy (or set)Property just the 
static calls currently except, it could be configurable!

Now, maybe such mappers would actually be slow things to load... I 
don't know...

Instead we have subclass-based attribute-conversion parametrization 
currently as in UseBean, right ?


Le 10 sept. 04, à 22:59, Hans Gilde a écrit :

> This is supported in a generic way by the jelly UseBeanTag and used in
> several places like the Swing tags. The way it's supported may look a 
> little inelegant in the code but I agree that it's certainly not due 
> to some huge deficiency in the BeanUtils.

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

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

View raw message