Groovy and Swing Bindings: Change is Inevitable
When I started writing the Groovy layer for JSR-295 (bean bindings) I deliberately chose to put it in the modules section for one simple reason: in case things in JSR-295 changed dramaticaly. Well, over the last few weeks they certainly have.
I personally applaud the decision, as it moves the core specification into something suitably general case: a method to bind two things together and to trigger actions from one to the other when a change is claimed to happen. Was it a bean property you were listening to? Use a BeanProperty. Do you want the update values to be determined by the Expression Language? Use an ELProperty. Want to trigger a change off of a remote JINI event and get the updated date from an NTP server? Roll your own, and you don't' have to smash it into EL syntax (unless you want to). My point here is that the JSR may now have easier use outside of the desktop and may have enterprise impliactions (four to six years from now when JDK7 becomes the base for Java EE, but I digress).
What does this mean for the current Groovy layer? When the new update comes out I will be able to build a new binding builder and even possibly integrate it into the SwingBuilder with a minimum of clunkyness. Possibly even making it a builder that takes another builder as an argument and passed through non-binding fanciness. Although I think it will only ever be used for the SwingBuilder, so it may as well be hardwired in.
This new approach should also allow for us to implement Jochen's goal of declaring bindings in the attribute lists. We can create a set of methods (named bind somehow) that return an internal
HalfBinding object. When the code that resolves properties in the properties list sees such HalfBinding objects, it can take the half of the binding expressed by the user and combine it with the bean being built and it's property name to create a JavaBeans Property and bind it with the Half Binding via the JSR-296. The other half can be in any form, and in fact we will want to override binding specific parameters (such as binding propagation methods: read only, bi-directional, etc.) We also are not limited to JavaBeans properties in the explicit half, we can do EL or even GString Syntax. Although we will need to monkey with GStrings to insure that they are evaluated at property change time instead of at decleration like the currently are.
So all in all, good things binding wise will be seen in Groovy, but not until after this fall's 1.1 release. Look for it in 1.2/2.0 (whatever the version name will be).