Geertjan is a DZone Zone Leader and has posted 467 posts at DZone. You can read more from them at their website. View Full User Profile

Porting to Griffon

  • submit to reddit

The Model

Finally, nice and cleanly in a separate file, called "AnagramGameGriffonModel.groovy", all our static variables are found, so now we know exactly where to look for them:

import groovy.beans.Bindable

class AnagramGameGriffonModel {
static final String FEEDBACK_NONE = ""
static final String FEEDBACK_CORRECT = "Correct! Try a new word!"
static final String FEEDBACK_INCORRECT = "Incorrect! Try again!"

@Bindable String scrambledWord = ""
@Bindable String feedback = FEEDBACK_NONE
@Bindable String guessedWord = ""

In addition, note that we have three bindables here. What is a @Bindable? As discussed here, "When a property has this annotation the AST Transformation will generate (if it doesn't exist) a PropertyChangeSupport object, appropriate listener addition methods, and then a setter that uses the property change support. The end result is a bound JavaBeans property, with a whole lot less boilerplate code."


So, finally, what are some basic truths that can be gathered from all of the above? Well, aside from the fact that I now also have an applet and a JNLP application (though not working completely correctly yet, for reasons I don't understand), I was able to use Groovy instead of Java to do my coding, while producing exactly the same result as before. The advantages of Groovy over Java is that one can code much more quickly because many of Java's stodgy requirements (commas, return statements, etc) are simply not required. (Though, if you like them anyway, you can continue using them in Groovy.) Another nice thing about Groovy over Java is that a lot of file handling is done in far fewer lines of code (look at "Flying with Griffon" to see how easily HTML or XML can be parsed).

Then, despite the fact that you're using the far less structured coding rules that Groovy provides, Griffon enables you to put all your files in very structured places within your application. That's structure that helps rather than hinders. In some ways, the difference between using Griffon and not using Griffon is the same difference as having a cupboard to put your clothes into and not having one. Your life will still be okay without a cupboard, except that all your clothes will be on the floor. 

In the porting process described above, I quickly discovered that the Matisse GUI Builder has made me a very lazy programmer indeed. I couldn't even remember how to set the size of a textfield. First I tried "size", then "width", then "length", and eventually figured out that I should have been using "columns". Hand coding user interfaces has always been hard and GUI Builders like Matisse have come to the rescue and have done so very successfully. However, in the process, aren't we producing a generation of programmers who don't know the first thing about layout managers? "Ah," you might say, "but you don't need to know about layout managers anymore." That may be so. I don't need to know how to fix my sink either, because that's what plumbers are for. But in an emergency, I don't have the first clue where to start. Not knowing about "columns" is equivalent to not knowing how to shut off the mains when a pipe bursts. However, in this context, some layout managers are better than others when hand coding, and my guess is GridBagLayout is not the best for hand coders but, as I said, I was trying to be consistent with the original application. An exploration of MiGLayout and GroupLayout in this context is next on my agenda.

Finally, I'm not necessarily advocating porting all Swing applications everywhere to Griffon. I'd say it makes more sense to port to a framework that offers at least a docking system, because that will then provide the opportunity for the application to grow. If Griffon were to offer those kind of services (i.e., services for Swing applications like those provided by Spring RCP and NetBeans Platform), it would suddenly find itself in a very different ballpark, one that it probably is less interested in. On the other hand, for small/small-ish applications (i.e., that don't need a windowing system) that make use of Swing, i.e., applications that are small and will stay small, even the pure intellectual exercise (on top of the wonderful opportunity of using Groovy in a structured context) of moving it to Griffon is something worth considering. Like picking up your clothes and putting them away is also worth considering. Speaking of which, I should probably go and do just that...

fig-1.png11.5 KB
fig-2.png11.43 KB
fig-3.png58.63 KB
fig-4.png11.42 KB
Published at DZone with permission of its author, Geertjan Wielenga.