That's pretty cool but horribly impractical. What I'd like to see is how binding would work to a true domain object vs some "example only" worthy ObservableMap that no one really uses to store form data in.
What everyone needs is the ability to easily bind forms to POJO's and back. Just like all the wonderful web frameworks can do. Let's see those kinds of examples if you really want to impress.
Horribly impractical... true, nobody in their sound mind should use an observable-map-as-POGO-replacement instead of regular domain objects when it comes to production code, for prototyping and testing I would think otherwise. An example with true domain objects you say? you got it! As I said ObservableMap works like an observable POGO, it simplifies testing as you do not need to declare a new class for your observable POGO, you just use the behavior, after all Groovy has blurred the line between Maps and POGOs. So what does it take to make a POGO an observable one? following the JavaBean conventions it means
- Each observable property must fire PropertyChangeEvent when its value changes.
- The bean should expose register/unregister methods for PropertyChangeListener.
- The observable behavior (firing events) may be implemented with PropertyChangeSupport.
That's it. Import the annotation, annotate the pertinent properties, bind to your hearts content. But wait there is more, it turns out there is a way to streamline the binding form textField.text to textModel.text. SwingBuilder includes a factory for building any node/bean you'd like, aptly named
bean. If we use that factory and set textModel as it value then we can also use the short binding syntaxMuch better. You may be wondering, what happened to the trigger code (PropertyChangeListener)? well that remains the same, it doesn't matter if you have an ObservableMap instance of an observable POGO, there is no short syntax for triggers for the time being.
Keep on Groovying!
