With the release of GWT 2.1, I’m going to try to put together a blog post about each of the new features. We’ll start off with my favourite addition, the data binding framework. If you are interested in GWT 2.1 coverage, make sure to check out Thomas Broyer’s blog, which covers Places extensively and Activities with nesting. Last, but certainly not least, the excellent GWT documentation has been updated to include 2.1 features.
One of the killer features in GWT 2.1 is data bindings. The GWT blog put it best.
Data bound views – An app that doesn’t allow end users to view or edit data isn’t terribly useful, now, is it? With GWT 2.1’s Data Editors, developers can create views that are generated from their app’s data model. These views are completely customizable, and handle all of the nasty work of syncing change sets between the client and server.
While data bindings are not new by any means, you usually find them in more traditional web frameworks like Seam, Spring Web Flow, etc. Now, this powerful paradigm has found it’s way into the best (IMHO) RIA framework.
Single Binding
Let’s cover the simplest case, data binding a single Java bean. For example, a simple Email POJO.
The Serializable implementation is only required for GWT-RPC calls, not the Editors framework. Also note that these objects do need getters and setters, you can’t modify immutable objects. Immutable objects can only be used for display.
Now you need a GWT widget to represent the Email object.
EmailEditor is a standard GWT widget, the only new piece is the Editor<Email> bit. This is the cue telling GWT that it is indeed a data bindable widget. If the field in the widget is named the same as the corresponding POJO field, the binding is automagic. Otherwise, you can use the @Path("") annotation to indicate the name of the field (or reach into nested values).
The final piece in the data binding story is the interface that will be GWT generated with the GWT.create() call. This does the required code generation to do automatic data binding.
This code could either go in some new class, or could be stuffed into the Presenter component if you follow the MVP pattern. Regardless, that’s all you need to bind to a single object.
Of course, in most cases, you have an entire object graph, so lets move on to binding a whole object graph.
Nested Binding
It turns out that data binding an object graph is as easy as binding to a single object. Take the Customer object.
Again, a regular POJO like we’ve seen before, but this time it has an nested Email and Address. Let’s take a look at what the Editor looks like.
As you would expect, editing the nested objects only requires including the editors for those nested objects. Finally, instead of having a Driver for each Editor, you create one Driver for the top-level Editor. In this case we define the driver in the entry point.
That’s about it. All your existing boilerplate that does data binding evaporates with some GWT generator magic.
We’re done for now. Part 2 will dive deeper into Editors and explain using interfaces, integration with GIN and using Editors with the new MVP framework.
More Information
Some additional documentation to check out for now.