... And They Shall Know Me By My Speling Errors

Groovy's Swing support is good, but can be improved. Julian Doherty has pointed out that there is currently no Groovy way to do data binding to GUI elements. In reality this is more of a problem with Swing/Java than with Groovy. But in my estimation it's not that there aren't enough ways to do binding, it's that there isn't a Groovy way to do bindng.

I hate to be the Knight who says "NIH" but all of the existing frameworks don't quite have the needed groove. JGoodies Binding, for example, has really nifty stuff including buffered updates and complex list editing support. But according the the author there is a steep learning curve and it is best suited when one person can master the classes. JFace is best suited for SWT programming.

The up and coming binding framework is JSR-295. However, I think it will suffer from one horrible crippling detail, dependance on the Expression Language, intially developed for JSP. You know, I was part of the expert committee for JSP when the EL was introduced. My role? Sitting there with my eyes closed and my fingers in my ears singling "LALALALA" and hopeing it would go away. It didn't. But my reluctance to embrace 295 for Groovy binding is not that I feel EL is a red headed step child only fit for the web tier (only a slight exaggeration). But my feeling is that if we are going to do things like property type conversions, validation, and complex declarations of which properties are going to be bound is that such things should be done with closures, not another interpreted text string. But since an API review still has yet to be released, it is unknown whether it is suitable to be used under the covers or not.

If I had to do it what would I do? I would likely build a new Builder: BindingBuilder. Why not build it into swing? First, binding may be useful outside the context of GUI Widgets, like JavaBeans events are currently modeled. Second, if you read the specs multiple binding templates can be defined in groups and applied in a pick and choose fashion to groups of elements, making it one to one with a SwingBuilder makes that hard. Third, we can add it as a related class to SwingBuilder by creating one if needed by adding magical methods, like is done for all of the widgets currently.

Next, I would build the binding off of a single core flow: First some trigger is tripped (either via event or explicitly). Then, values are read from the source, via some closure friendly means. Next the inbound data is massaged in some closure friendly means. At this step the binding can be aborted if the massaging logic says so. Finally, if the massager likes it, we will apply it to some target via a closure friendly means. If it sounds a lot like how the JavaOne Slides describe JSR-295 it is meant to, with some closure friendly means and a whole lot less statically typed interfaces.

Finally, I would write a boat load of convenience methods in the builder mapping common patterns to the single core flow. Property syncs are easy. Bi-directional syncs are on by default, but can be turned off by a property in the builder. Table selections, column selections, list to table mappings. All of this done with the aim to reduce typing when you write the code. Less typing of the keyboard and less typing of the objects, let the binding builder do that for you.