If you're saying that all we have to do is write a class that implements the BeanUtils interface Converter, where the Converter uses JEXL to do the conversion, then I'm right there with you. This would allow us to mix and match pure-Java converters (declared with a class name) with JEXL converters (declared with some JEXL code).
However, the "instance-based set of converters" doesn't help us here. Because even in an instance of BeanUtils, you can't attach a converter to a specific property by name. Only to all ints using that instance. For example, the old Swing ComponentTag (old meaning the version immediately previous to HEAD) set the String-to-int converter to a converter that handles the syntax for the JComponent setGraphicsDebugOptions(int) method. Unfortunately, this broke all other int-based bean properties. But don't let any of this worry you. If we come up with a good way of declaring converters, it will be no problem to implement it. Just as long as we separate the discussions of "whether to use BeanUtils in core Jelly" and "how to implement per-bean-property, declared converters". A basic proposal for conversion and the general configuration of TagLibraries and Tags: * Each TagLibrary has an optional XML descriptor. This descriptor specifies, at least, the main TagLibrary class. This is a JSP concept. Namespaces can then map to descriptor files, just like JSP. Or they can map to TagLibrary class files that have no descriptor. * The descriptor is, obviously, a Jelly script. The descriptor is therefore free to configure the TagLibrary class as its tags see fit. * Since the descriptor can call methods on the TagLibrary, it can register custom mappings using a yet-to-be-defined tag library custom-mapping-registration-interface. The base TagLibrary class will support the registration and actual use of these custom mappings. * The descriptor can be extended with new descriptor-tags to use any configuration option that is supported by the Taglibrary class. * The descriptor is transformed directly into documentation. So, it serves two purposed: configuration and documentation. * If the TagLibrary or Tag classes want to declare documentation and default configuration without using the descriptor, they must use XDoclet. The XDoclet tags will generate a separate XML file, not the descriptor. This XML file, the "generated descriptor", will be merged with the descriptor so that documentation/configuration can come from both XDoclet and the TagLibrary descriptor. I know that this is complicated, I'm just throwing out all the ideas at once to be shot down. Hans -----Original Message----- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 14, 2004 3:44 AM To: Jakarta Commons Developers List Subject: Re: Jelly and a new beta release So that means that it would be easy, with this instance-based set of converters, to write a converter: - attached to a mapping type (attribute-value to class xxx) - attached to a named attribute (note, attribute values are not always strings! they're jexl results) For example, the FontTag could attach the default style-constants to the style name or the border-layout the constraints constants. Still allowing some cross-usage (I think there are some constants)... The wish to make it declarative: building such converter for text to int is easily done in, say, an xml-snippet. Using this, documentation can be written and that's important (that may even be more usable that javadoc for this!). Agreeing ? paul Le 12 sept. 04, � 18:14, robert burrell donkin a �crit : > the basic changes is that now instances are used to back the main > methods. the static methods now select a psuedo-singleton instance > (one per context classloader) and use that to execute. it is now > possible to use separate, distinct instances and bypass the static > methods completely. > > i strongly suspect that the way that jelly uses beanutils may have big > problems if used in any multi-threaded environment (not just swing). > the simplest way to fix this issue would be for jelly to replace calls > to the static methods with calls to a concrete instance. however, i'm > not really sure that this would be the best general approach (though > it may prove a useful default). i'll pick up this theme up on list. --------------------------------------------------------------------- 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]
