The SwingX widgets have been a pleasure to work with in the past, and with the swingX plugin, it takes not a single line of extra code in order to use them.  The underlying SwingXBuilder provides factories which override the standard SwingBuilder syntax to replace the standard widget set with the SwingX equivalents. Simply add the prefix ‘jx’ to the standard SwingBuilder node calls and you’re in business.

Along the way I’m going to incorporate the fest and cobertura plugins to test out the UI. I’ve never used fest before but it seems that the only real requirement is to remember to give your components a uniquely identifiable id. There are additional ways of looking up components with fest, for sure, but unique ids should cover this application’s needs quite nicely. Using both together is a simple exercise on the command line.

griffon run-fest -cobertura

Under the hood, Griffon uses TestNG, so the test class can also take advantage of some nice familiar annotations to assist configuration. Code coverage and testing results are provided by default in an html format, which anyone who likes their test coverage will be infinitely familiar with.  All in all, the experience of setup and execution of the testing framework is pretty painless.

The SwingSet demo is actually laid out pretty nicely for testing in the first place. There’ s a top level MainWindow class, which accepts a DemoPanel parameter. The full demo launches with a SwingXDemo subclass of DemoPanel that aggregates other subclasses of the same into a tabbed pane. Tests are free to call the MainWindow class with any of the individual panels as a parameter, so testing them on their own using fest looks like it would be a cinch.  In Griffon terms this roughly translates to a root MVC group that composes another MVC group that is specified by id. Easier to show than to explain, with an example of a call that would go in the controller:

createMVCGroup(mvcGroupIDParam, uid,   [... param map ...] )

The first thing created in the SwingSet UI is the menu, so that’s what I created first as well. In the view class:

 actions {
    action(id: "quitAction",
            name: model.QUIT_NAME,
            mnemonic: "Q",
            accelerator: shortcut("Q"),
            closure: controller.quit)
  }

  menuBar {
    menu(model.MENU_NAME) {
      menuItem(name: model.QUIT_NAME, action:quitAction)
    }
  }

The component names are defined in the model class so that they can easily be extracted later for testing purposes.
Including the fest plugin with Griffon adds a target which is used to create a new test, which will prompt you for a test name.

create-fest-test

The new test class is created with all of the necessary code to let fest launch the base application frame. This first test is very simple, just making sure that our single menu item is present in the GUI.

  @Test
  void testQuitMenuItemPresent()
  {
    Assert.assertNotNull( window.menuItem(GriffonSwingSet3Model.QUIT_NAME) )
  }

That’s really all it takes to launch a new application using the test harness and verify UI component state. Man, can I think of a couple of times in the past where that might have come in handy

Next, step is cutting over the first SwingSet DemoPanel, a demonstration of JXBusyLabel – 635 lines of the usual Swing inner classes and boilerplate GridBagLayout constraints code. Really looking forward to seeing how it looks in Groovy.

Related posts:

1. Griffon SwingX Fest testing
2. Fun day playing with new Stuff
3. VIJUG Griffon/Groovy Presentation

I’ve experimented a bit with Griffon a bit lately, but still being somewhat of a Groovy noob, I don’t think that the full impact hit me until I started reading the book. Maybe part of the problem is not that it’s hard to understand, but that it’s hard to believe that it’s so easy.

A very clearly defined way of separating the classic MVC. Injection of views, models, controllers – all available by convention not by annotation, xml configuration or even having to a refer to a component by name. The transparent access to a variety of builder actions through plugins makes a large toolset available with little or no cost. Clear architectural boundaries exist that guide you to where your code should be developed. The Griffon framework, created with gracious acknowledgement to its forerunner Grails strives to do one thing above all – make Swing easy.

The power and versatility of Swing has always been obvious to me. The ‘magic sauce’ that makes large scale Java Swing applications behave in any sane way has been a little more hazy. The advent of SwingWorker and other enhancements to the Swing toolset and the availability of better documentation have certainly made the landscape a lot more tolerable, but at the end of the day, it’s still hard to even find good examples of large Swing apps to use as a guideline(well at least it has been for me.) On the other side of the spectrum, I’m not sure there IS such a thing as a small Swing app. The amount of boilerplate code required is cumbersame, to say the least, and between anonymous inner classes for actions/listeners and correct handling of business logic and the EDT by the time you’ve finished doing anything moderately significant you’re already a couple 1000 lines in.

Griffon takes all that and hides it behind a curtain. Expanding on the already powerful SwingBuilder capabilities, it provides a quick and easy way to develop complex Swing applications. Utilizing @Binding to provide easy view/model interaction and baking the Observer pattern right into the framework make it beyond simple to deal with GUI events. And the pattern for dealing with EDT issues couldn’t be much more straightforward.

doOutside {
.... do whatever you need to do off of the EDT
doLater { ... come back to the EDT when you're done to update widgets }
}

I’m pretty sure that’s an easy enough pattern that I will never again forget the cost of doing… well pretty much anything that takes +1 second while blocking the EDT.

Personally, I’ve run into a couple of unexpected results when trying to utilize the webstart version of the application, but other than that everything has worked exactly as advertised. And at the end of the day I’m willing to chalk that up to my misuse of the system. I’ll tell you for sure when I get to that chapter of the book. Which will probably be about 2 days after the authors publish it.

So far my impression of the pre-release chapters of the book are pretty good – well written, clear and above all – the code samples work. Kudos to the authors Andres Almiray, Danno Ferrin and Geertjan Wielenga.  Look forward to the rest of the book boys, and to writing some new Swing apps with Griffon!

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. SwingSet on Griffon
3. Griffon SwingX Fest testing

I got a chance to work with the brand new Griffon framework and must say – the combination of clear MVC architecture, Grails style convention over configuration and already powerful plugin selection make it pretty sexy.

The early support for cobertura code coverage and fest GUI testing are both appealing to any developer that appreciates the need for testing your application.  I’m still undecided on the Grails-like adoption of storing project information in a “.griffon” folder in the user directory and completely outside of the actual project directory structure. With luck, future versions will allow for incorporating maven to handle dependency management and get me past my FUD on that one, something that the latest Grails supports. I haven’t yet tried that new feature out in Grails out so I’m not entirely sure how well it works, but the docs say that there is a provided archetype and that all of the familiar Grails targets are mirrored in the maven goals.

Being able to add additional Groovy style builders as plugins is about as transparent as it gets – install the plugin and you can immediately incorporate that builder anywhere in the application.  The only builder component set that I have had a chance to work with previously is SwingX, but anyone who’s had the opportunity to use a JXTable in place of the vanilla JTable can immediately see the advantage! And the JDirectoryChooser from l2fprod is a powerful alternative to the Swing built-in JFileChooser.

The crown jewel so far however seems to be  the wizard plugin. This addresses what is  a very common scenario in any process related application:

• collect User input in a series of steps
• validate the input at each step
• allow the User  to go back and review or change any inputs
• apply all of the input to an underlying business process
• provide feedback as to the result

The wizard framework worked pretty much as advertised right out of the box and, although the project seems to have stalled (couldn’t seem to  find any updates since mid-2008) , when integrated so well with Griffon it seems a very good candidate for building lightweight applications – installers in particular jump to mind.

Any way you look at it – for a project as newly arrived as Griffon, it’s already promising to be a very powerful enabler. Thanks to Andres Almiray and everyone else involved in the project. I look forward to using Griffon more in the future.

Related posts:

1. A One Day Griffon Application/Presentation
2. Playing with the new Grails :)
3. SwingSet on Griffon