Swing
Let's have a look at the Swing version first, it will serve as baseline for comparison with the other toolkits.
Let's see what we have here: a window with 4 widgets (label, input, button, input) arranged in a vertical layout. Clicking on the button copies the text from the first input into the second. Here's the View code:
Looks like the input fields have their text property bound to model properties, the button triggers an action defined on a controller. Now let's see how the Model code looks like:
Writing observable beans in Groovy is so simple it makes you wish @Bindable was available back in the early days. Finally here's the Controller:
And that's all for this application. I told you it was a simple one, didn't I? This version takes advantage of SwingBuilder's binding options, that's how the Controller is able to update the View just by updating the Model and not the View directly. Now for something completely different, yet familiar.
Gtk
Gtk support is underway, it has been possible thanks to the efforts of the java-gnome project. In short java-gnome provides bindings for using Gtk widgets from Java. Screenshot follows.
You can argue it resembles the Swing example a lot. But what about the code? Here's the View:
It looks remarkably the same! Of course there are a few differences on closer inspection. Gone are the imageIcon properties, replaced by pixbuf. Gtk widgets do not support binding like Swing does (they do not publish PropertyChangeEvents, the basis of the binding mechanism as applied by SwingBuilder) though it may be possible to provide some, notice how the first input updates the model with an explicit event handler. The button triggers a controller action, same way as before, the only thing that changes is the property name. Next is the Model:
There's no output property on the Model as we won't be able to update the View by changing model properties. You could argue @Bindable is technically not needed but decided to leave it there. The Controller will surely look different given all these changes, won't it?
Not really! The controller updates the View by reading a Model property then setting the value on a View element directly. Surprisingly the next toolkit we'll explore yields a similar set of MVC members.
Pivot
Pivot is the most recent addition to the set of available UI toolkits on the JVM. Its design has been driven by the need of a new platform for building rich internet applications in Java. Obligatory screenshot follows
Perhaps one of Pivot's features that will catch your attention first is its styling support, as demonstrated by the View code:
This View resembles the Gtk one a lot! Look at the subtle name changes on the input widgets and their events, other than that the code is pretty much the same. It follows that the Model and Controller will be similar, let's see if that assumption holds true, shall we? Here's the Model:
The assumption held true for the Model (the class name was the only thing that changed), what about the Controller?
And indeed it does! Not bad, eh?
Pivot "suffers" the same problem as Gtk from Swing's point of view: it does not fire PropertyChangeEvents whenever a property changes value. However its listener hierarchy is very deep and rich, and most important for many: it's type safe, as Pivot requires JDK6 at a minimum due to its wide usage of generics and modern JDK features. But if it's possible to bridge the binding gap with Gtk then it should also be possible to do the same with Pivot. The final participant approaches.SWT
There's been a lot of electronic ink devoted to the Swing-SWT wars. You will see a different story here.
I must confess I have no knowledge of SWT beyond the occasional blog showcasing simple examples, the following View code can certainly be streamlined. I was able to write the View just by following the conventions set by the Builders:
Again the code's verbosity is mostly my fault but the basic layout shared by the other implementations is there. There are no references to model properties in this case, the Model should be empty:
This leads us to the Controller
SwtAppController copies the text from one input to the other by accessing the widgets directly. I've been told that SwtBuilder sports a binding solution similar to SwingBuilder, which means this example can be improved in the future by adding proper binding definitions.
That's all for now. I think the main take away from these examples is that you can develope a desktop/RIA application with Griffon no matter the toolkit of your choosing. In the case of Gtk-Griffon, it may be possible to develop an application "Quickly" and productively, details will follow soon
.Keep on Groovying!
