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]
