In message <[EMAIL PROTECTED]>, Paul Libbrech t writes: >I keep believing, however, that such a thing should be done by Jexl or >something else... it makes no sense to need this getStatic, at least >compared to Java.
I agree. After I shot off my email I was going to reply to it and add "maybe the right thing to do is enhance Jexl?". When trying to access static constants, the first thing I did was try to use the Jexl expression language, figuring it must support such a thing. After the error messages, finding the Jelly invokeStatic tag, and digging through what documentation I could find, it became clear I couldn't do it with Jexl. I suppose since Jelly supports multiple expression languages, it may be possible to swap in another language to do that sort of thing. I'm new to Jelly and don't know what the preferred approach is to do certain things in a manner consistent with its design. My gut feeling is that the expression language should support features like invokeStatic or my proposed getStatic, but when I see all of the Jelly flow control tags I figure I do not yet understand the intended relationship between Jelly and Jexl or Jelly and another expression language. When does some feature belong in Jelly (or user-implemented Jelly tag), when does it belong in the expression language, when does it belong in a user-implemented JavaBean? As best I can tell, the expression language isn't supposed to do flow control, just evaluate embedded expressions. Based on that Jexl seems like the right place to add static field access. Yet expression manipulation is limited to JavaBean properties (otherwise there would be no need for the invoke tag), which makes it seem like Jexl isn't the right place. If static field access were to be added, why not arbitrary method invocation? Anyway, that's a long-winded way of explaining why I do not yet understand the design guidelines that help dictate what should go where. >Yet an alternative way for this was partially done in >GridBagConstraintBean: namely it has been tried to have custom >converters that would decode such (expected) constants into an integer. The downside to doing that would seem to be that you may have to write a converter for every bean? Or is there a way to do it once for all of them, where by default Jelly would try to match unknown properties against constants? I suppose that's where your mention of BeanUtils comes in. But with a converter, am I correct in assuming you couldn't throw in a constant defined in a different class? >Feel free to go ahead but let's start this discussion on the usages of >converters in jelly-attributes since it seems BeanUtils folks are >"eagerly expecting users" ;--> I think I'll hold off on doing anything until the discussion runs its course. So far, it seems there's agreement that it's useful to be able to access static class fields, but there's more than one way to do it. Before shoehorning getStatic into jelly core, it may be best to explore the alternatives. Another possibility is to overload invokeStatic so as to avoid adding another tag and have it behave like getStatic if a "field" attribute is defined and like invokeStatic when a "method" attribute is defined and throw an exception when both are defined. But that's probably overcomplicating things and not in the spirit of how things are done in Jelly. Otherwise, there would have been no invokeStatic tag and the invoke tag could have been made to behave like invokeStatic if a static="true" attribute were present, expecting the "on" attribute to define a class name in that case. BTW, I'm so glad you mentioned BeanUtils and converters. I have a need right now to take a bunch of beans (remote MBeans actually) and dynamically create Swing components that let you change bean properties and invoke methods. I was fearing (because of the time involved) having to write a bunch of code to convert strings into method parameters. BeanUtils is exactly what I need and it may have taken me a while to figure that out on my own. So count me in as an eagerly expected user. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
