a few comments (in no particular order)...
allowing tag libraries to declare bindings sounds like the way to go. in addition to the advantages already outlined, it might allow the possibility of generate a concrete binding implementation for a tag library. generated bindings are quicker than dynamic ones that use reflection.
there are two real parts to beanutils: the bean query language and the conversions. i suspect that since jelly has JEXL, it doesn't need to use the beanutils bean query language. does anyone know whether this is correct?
it'd probably be better to factor the bridging conversion code into jelly (rather than beanutils). that way, anyone who wants to create a tag library that uses some custom mechanism can do so more easier. this would allow a jelly specific interface rather than a generic one.
- robert
On 11 Sep 2004, at 01:32, Hans Gilde wrote:
I like this idea. At the moment, we do have subclass-based attribute conversion.
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 [mailto:[EMAIL PROTECTED] 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 ?
paul
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
