The slideware plugin provides a framework for creating presentations with a little twist – you can execute code live from the presentation software. If you’ve ever given a presentation about programming you probably are fully aware of the transition from presentation software to your preferred environment for demonstrating code samples. Well, now you can stay entirely within the same application, editing and running code live.

The plugin itself isn’t available from the Griffon repository but source code and a built 0.2 version can be found on github. Considering both the youth of the plugin and the beta status of the framework, it worked impressively well AND had a rich feature set. All of the expected “powerpoint” features are there: themes, layout control, styling, slide transitions and export are all pretty easy to incorporate and configure. The code editor view also works very well. A great variety of additional plugins are harnessed to put all the pieces together and as a result building one of these applications is a great way to tour the platform.

Theming

Applying a theme to the presentation is simply selecting a Java Look and Feel to apply in Initialize.groovy. The Substance jar is included with the plugin so I test drove a few of the nice setups in there and finally settled on the SubstanceMagmaLookAndFeel. There is definitely a wide variety of L&F’s to choose from in that bundle alone and, although I haven’t done it myself, they seem pretty tweakable as well. Plus any old L&F should plug in nicely, I would imagine.

//Initialize.groovy
SwingBuilder.lookAndFeel('org.jvnet.substance.skin.SubstanceMagmaLookAndFeel',
       'mac', 'nimbus', 'gtk', ['metal', [boldFonts: false]])

Layout

Controlling the page composition is a standard Swing Layout or, in the case of the default slide you get with the included “create-slide” script, a MigLayout. Framing the standard variety of slides is very simple. Bulleted pages, title slides, code slides and custom layouts are very easy to accomplish. I don’t have a lot of experience using this particular layout but the presentations Andres has made available on github have a good diversity of examples of how they look in practice.

//the default create-slide generated template
import net.miginfocom.swing.MigLayout

slide(id: "slide0", layout: new MigLayout("fill","[center]","[center]")) {
    label("Insert your text here")
}

Styling

Styling is supplied by the css plugin, on which slideware has a dependency. The default style.css file sets out just some reasonable defaults for the fonts used in different parts of the app, and I didn’t see any real need to fiddle with it. Especially happy to see the nice monospace code font. On a totally related note I recently installed the Inconsolata monospace font to try for development and I’ve been very happy seeing it in my editor, but it’s still nice to see this kind of polish applied to the presentation. The code editor view even includes syntax highlighting! More on that coming right up…

Slide Transitions

Moving between slides with style is the responsibility of the transitions plugin. You can see see all of the animations this plugin enables over here at this page describing Transitions and Transition2Ds. Pretty slick stuff and defined as simply as a parameter to each “slide” node in a script.

slide(id: "slide3", layout: new MigLayout("fill","3%[center]3%","3%[center]3%"),
        title: "Junit3",
        transition: new FlurryTransition2D(Transition2D.OUT)) {
    scrollPane(constraints: "grow") {
        widget(createEditor(text: script))
    }
}

Code Editor

Code slides embed an editable widget and allow for composing and executing Groovy scripts or classes of arbitrary complexity. You can execute the code with a keyboard shortcut and a window will open displaying the console output. The code itself is executed through a GroovyShell, enabling pretty much anything you might want to do. If you have an internet connection and the required repositories configured, Grapes simplifies packaging the dependencies for the application as your code samples can directly Grab the jars they need. Basically, the first time you execute a code slide you’ll have to put up with a small pause while Ivy downloads to your local repository, unless of course the required dependencies are already there. In my case I changed strategies from including jars in the application lib directory to a Grapes approach and I think it’s a better way to go.

I was surprised to find that the editor even included undo functionality. It’s definitely not close to a full blown IDE, and there’s absolutely no reason that it should be. For the task of demoing simple code examples it’s more than up to the task, even to the point of maintaining your edits between slide transitions, allowing you to move back and forth through the slide deck without any state problems.

Export

The application includes a “Print” feature which iterates through the entire slide deck and renders it to a pdf. Distribution of one of these presentations is really very easy, including the ability to create installers for all major platforms simply by adding the packaging plugin.

Test Application

The test app I built while looking into this is pretty simple. It’s got a title slide, a bullet slide and 4 code slides. The code simply demonstrates how you can create test classes and make assertions for Junit 3(with GroovyTestCase), Junit 4 and TestNG. GroovyShell recognizes all 3 of these test files by interface or annotation and executes them appropriately. In each case the console output of the test framework is the result, including the new Spock inspired ascii art assert failure renderings. The Test result files are also written to disk, and that TestNG html output is what I’m used to looking at anyhow. Show me the Green!

The last code slide is just a slightly updated version of an example script on the Grapes page, using the current version of Google Collections and intentionally introducing a failure- mostly just to show off that new assert rendering I mentioned a moment ago. VERY helpful at highlighting the exact nature of a failure. It also encourages me to pay more attention to how I name variables, something I’m sure every developer that has ever worked with me will cheer at. Man, I suck at naming things.

I also developed a brute force test that loads each slide and executes scripts if finds embedded there. Failures are hard to detect since the direct output is simply a text block, but some fairly simple regex’s applied to the output make me at least moderately confident that the code won’t fail at show time.

Overall Impression

It took a couple of afternoons(six hours or so total) to download the source code from github, explore it, create a simple presentation and document the experience. I won’t begin to suggest that I’m fully aware of all the details happening behind the scenes, but the end user experience is pretty fluid: create a slide, tailor the layout, add content and then repeat. The included examples were more than enough documentation on how to hit the ground running. The plugin code itself is a great example of the MVC nature of Griffon, not a whole lot of code, but a great deal of power and expressability. There were a couple of glitches happening in the background, mostly just logging to the console with no visible effect to the application, but overall it functioned as well as (not) advertised. For publicly unreleased software it was an absolute pleasure to work with and I plan on continuing with the development of this particular presentation.

Everything you need to build and run this stuff yourself is publicly available. In my case, Griffon generally has a recent Macport available for both the released(griffon @0.2.1) and development versions(griffon-devel @0.3-BETA-2). Switching versions is relatively painless and, for applications this simple, testing out upgrades is basically just going through the presentation once in a functional test. Versions for other platforms can be downloaded from the Griffon download page.

Deliverables

Source code for the sample application is available on github here. Please just leave a comment on this page if you have any problems running it.

Here’s the pdf produced by the application ‘Print’ feature: Groovy Testing Presentation (252)

And if you don’t feel like downloading anything, here’s how it all looks in pretty pictures.

[Show as slideshow]

[View with PicLens]

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. Achieving Groovy-like Fluency in Java with Google Collections
3. Fun day playing with new Stuff

The venue was great – very nice that the Vancouver Island Tech Park is kind enough to host meetings. Next time I’ll have to come early enough to figure out how to make the projector do better than 800X600 resolution, however. Hard to show much other than a slide deck presentation with that little space. Then again I may be a little spoiled when my usual is 1920X1200.

I love using Keynote for presentations with the Apple infrared remote. Between the presenter view with notes to guide what I wanted to say(and to remind me when to step out and demo some code) and the timer to keep me on track, it went really pretty smooth. That’s my story, and I’m sticking to it. The software, both Griffon and Keynote, worked flawlessly so if things weren’t perfect, there’s only me to blame.

SwingPad seemed to make quite an impression, which is not hard to understand considering how little effort it takes to start showing results on the screen. Put that together with the recent CSSBuilder integration and the rich samples for other builders and I think more than a couple of Java developers will be installing it soon.

The question came up enough that I want to directly reference this blog post from Andres Almiray regarding GSQL in Griffon. Apparently people like to have databases handy at all times

And a big thanks to Andres for sharing two free copies of the upcoming Griffon In Action that he is co-authoring for raffle prizes tonite. Through the magic of Twitter he was very supportive about 20 seconds after the original announcement went out. Now if only they can kill all those nasty spam-bots, etc that are messing with my Twittiness!

I’ve uploaded the demonstration application at github. It shows a simple Griffon app with three tabs. The first is a minor port of Andres’ Trident/GfxBuilder example to show animation. The second is a simple demo of the @Bindable AST transformation along with the SwingBuilder syntax for accesing SwingUtilities; it comes along with an accompanying Fest test. The third requires an internet connection as it parses out the DZone rss feed and delivers it into a GlazedList, demonstrating usage of SwingWorker courtesy of the SwingXBuilder. I showed those samples along with installer plugin built versions of some of the included Griffon sample applications. WeatherWidget is a one fine looking translucent UI example!

Please ping me if you have any problems running this Griffon app, as I did trim out a bunch of the extraneous project files and test reports right before uploading. This was my first time ‘really’ using Git for source control so it’s bound to be a bit messy – nevertheless the Git experience has been great so far. I also tried to get the slides up on SlideShare, but that appears to… not be happening(been uploading now for over 20 minutes this time- about to kill it, again). So here’s the pdf.
Source code download here.

Slidedeck download here.

Related posts:

1. A One Day Griffon Application/Presentation
2. Griffon SwingX Fest testing
3. Presenting a Groovy/Griffon talk

And recently I had read an article about GlazedLists over on Andres’ blog, so it was great to get some more context around them, especially on how they can greatly simplify development of responsive and scalable Swing tables. It inspired me enough to visit their developer tutorials page and spend an hour watching screencasts. The examples are clear and concise, and the developer, James Lemieux, does a fantastic job of explaining how the different pieces in the GlazedList architecture fit together. If you have a spare hour, well worth watching.

So in the spirit of my last post, it occurred to me how to put this to use on the command line as an example. I chose to do a quick and dirty script for sorting a subset of the results from an ‘svn st’ command run in the current directory. Not terribly useful in its present form, but I think it shows that with a little more effort, you can add some handy utility methods when consuming command line output – namely sorting.

Essentially this is a demonstration of creating a table binding dynamically and baking automatic sorting across multiple columns right into the model. Grape is used to incorporate the GlazedLists functionality, but otherwise all of the dependencies required are available in Groovy 1.6.1. So you can run this directly on the command line of a *nix machine(execute permissions required of course) with very little additional setup. I did have an initial problem with Grape being unable to resolve the GlazedList dependency, but through the magic of Google I found this article which explains how to configure repositories using a grapeConfig.xml file and the problem went away. With no further ado, here’s the entire code.

#!/usr/bin/env groovy
import ca.odell.glazedlists.*
import ca.odell.glazedlists.gui.*
import ca.odell.glazedlists.swing.*
import groovy.swing.*
import javax.swing.*

@Grab (group = 'net.java.dev.glazedlists', module = 'glazedlists_java15', version = '1.8.0')
public class SVNGlazedListExample
{
	public static void main(args)
	{
		def columnNames = ['Code', 'Revision', 'Filename']
		def sortedRevisions

		//execute on the command line and populate buffers with the output
		def sout = new StringBuffer()
		def serr = new StringBuffer()
		def Process process = "svn stat -u".execute([], new File('.'))
		process.consumeProcessOutput(sout, serr)
		process.waitFor()

		SwingBuilder builder = new SwingBuilder();

		/**
		 * closure returns a JComponent showing the buffered output
		 */
		def getTableModel = {out, err ->
			if (err)      //Groovy truth FTW
			{
				//create error output table
				return builder.textPane(size: [500, 500], text: err)
			}
			else
			{
				//create three column table
				def lines = out.toString().split('\n')
				def data = []
				lines.each() {
					def tokens = it.tokenize()  //Groovy add which abstract away spaces vs tabs
					//a hack to be sure, but let's just get trebles for now
					if (tokens.size() == 3)
					{
						//rows in the data are just a map
						data << 1, revision: tokens[1], filename: tokens[2]]
					}
				}
				//passing in null gives us default String comparator
				sortedRevisions = new SortedList(new BasicEventList(data),null)

				//this little trick courtesy of Andres Almiray - Thanks!
				final EventTableModel model = new EventTableModel(sortedRevisions, [
						getColumnCount: {columnNames.size()},
						getColumnName: {index -> columnNames[index]},
						getColumnValue: {object, index ->
							object."${columnNames[index].toLowerCase()}"
						}] as TableFormat)

				return builder.table(id: 'revisions', model: model)
			}
		}

		//the 'show it' code
		builder.frame(title: 'SVN Change List', size: [500, 500], pack: true, show: true,
				defaultCloseOperation: WindowConstants.DISPOSE_ON_CLOSE) {
			scrollPane {
				def component = getTableModel(sout, serr)
				//I'm sure this could be more elegant
				if(component instanceof JTable){
					def tableSorter = new TableComparatorChooser(revisions,
						sortedRevisions, AbstractTableComparatorChooser.MULTIPLE_COLUMN_MOUSE)
				}
			}
		}
	}
}

UPDATE: A long time coming, but here's a screenshot for you Sho.

Related posts:

1. Achieving Groovy-like Fluency in Java with Google Collections
2. VIJUG Griffon/Groovy Presentation
3. A One Day Griffon Application/Presentation

Since FEST allows you to alter the properties of the widgets directly, I didn’t have to do anything special to trigger actions on the JXColorSelectionButton. At first look, I thought that specifying mouse click point locations would be necessary, but after digging a(very little) bit I discoveregroovyd that FEST exposes the underlying Component its’ Fixture classes wrap as an internal ‘target’. Simply grabbing that Component and settings the background color directly was sufficient.
Here is the new definition of the JXBusyLabel and the 3 buttons which controls its color changes. You can see that two of the three color changes happen automagically due to Groovy binding – setting the background color of the label didn’t appear to work for some reason that I have yet to puzzle out, so it gets a PropertyChangeListener ‘old school style’.

baseColBtn = colorButton(name: 'baseColBtn', background: model.baseColor)
highColBtn = colorButton(name: 'highColBtn', background: model.busyColor)
backColBtn = colorButton(name: 'backColBtn', background: PaintUtils.BLUE_EXPERIENCE.getColor1())
backColBtn.addPropertyChangeListener("background", {PropertyChangeEvent evt ->
      label.setBackground((Color) evt.getNewValue())
      label.setOpaque(true)
} as PropertyChangeListener)

label = jxbusyLabel(name: 'busyLabel',
      preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
      busyPainter: busyPainter(
      highlightColor: bind { highColBtn.background }, baseColor: bind {baseColBtn.background},
      points: bind {slider.value}, trailLength: bind {tSlider.value}),
      opaque: false,
      horizontalAlignment: JLabel.CENTER,
      delay: bind {speedSlider.value},
      background: bind{backColBtn.background})

The three associated tests are essentially using the same recipe, so here’s just one of them to give you the idea.

 /**
 * Test that changing the 'baseColBtn' background color simultaneously
 * changes the busy label's base color.
 */
 @Test void testBaseColorChange() {
       startAnimation()
       def button = window.button('baseColBtn')
       def busyLabel = findBusyLabel()
       Color start = button.target.background
       Color busyStart = busyLabel.busyPainter.baseColor
       Assert.assertEquals(busyStart, start)

       button.target.background = Color.RED

       Assert.assertFalse(button.target.background == start)
       Assert.assertFalse(busyLabel.busyPainter.baseColor == busyStart)
       Assert.assertEquals(busyLabel.busyPainter.baseColor, Color.RED)
 }

Running the test suite takes less than a minute, and most of that time is spend dragging sliders. Those tests are presently going through the entire range of the slider, which is reassuring when actually watching the tests run, but probably overkill in terms of testing. Considering that, running the test suite is pretty painless and quick(the new tests execute in < 1s for instance). And of course the test results are available in the standard, pleasing, and hopefully all green, TestNG output. Which has, by the way, just announced another release thanks very much to its creator Cedric Beust.

I am still having some difficulties in responding to change events on the other sliders in the demo, but I think that I just need to decompose the parts into the MVC structure a little more coherently. In particular, when some sliders are moved, it should trigger some calculations and a repaint of the busy label to reflect the changes(not simple properties that can utilize binding directly). While the original code declares the method inline, I’ve moved it to the controller class and run into some circular dependency problems between the components referenced therein – Component A needs Component B but it hasn’t been instantiated yet in the view, etc. It looks like what is happening is that the change listener is being triggered once when it is assigned to the component, which might be a problem anywhere in Swing/Groovy/Griffon/my implementation. My money is on my own impl, mostly based on the common sense that when you’re writing code in an unfamiliar area you’re bound to meet problems that don’t immediately suggest a solution.

We’ll just have to keep digging and see.

[Show as slideshow]

[View with PicLens]

Related posts:

1. Griffon SwingX Fest testing
2. SwingX busy label demo in Griffon and Groovy
3. A One Day Griffon Application/Presentation

So the SwingX demo has 3 sliders that affect integer values on the JXBusyLabel. Using the Groovy ‘bind’ syntax, responding to changes in these events is simple to say the least.

And as promised in the last post, I’ve written some FEST tests to validate that everything is working as expected. Stay tuned to the end of the post to see a video of the running tests

FEST provides some convenience wrappers for UI elements that allows easy access to common operations. Looking up a JSlider in the UI for instance, returns a JSliderFixture object with a nice little ‘slideTo’ method.
First off, here are the UI components under test. Yes, this is the entire code, including all necessary wiring to trigger updates automagically as the sliders are changed.

speedSlider = slider(
        name: 'speedSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: model.SPEED_MAX - 1, value: model.SPEED_MAX - 1, extent: 0),
        opaque: true)

slider = slider(
        name: 'slider',
        sliderModel: boundedRangeModel(
                min: 1, max: 50, value: 8, extent: 0), opaque: true)

tSlider = slider(
        name: 'tSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: 20, value: 4, extent: 0), opaque: true)

label = jxbusyLabel(name: 'busyLabel',
        preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
        busyPainter: busyPainter(
                highlightColor: bind { model.busyColor }, baseColor: bind {model.baseColor},
                points: bind{slider.value}, trailLength: bind{tSlider.value}),
        opaque: false,
        horizontalAlignment: JLabel.CENTER,
        delay: bind{speedSlider.value})
........
buttons.addLine(button(name: model.START_NAME, action:startAction))

And then the tests run against them. Each test moves a slider sequentially from the minimum to the maximum values and checks at each change to ensure that the same change is reflected on the bound JXBusyLabel property. Because the JXBusyLabel does not have a ready corresponding FEST built in fixture class, we just look it up as a Component by inspecting the UI for the appropriate named Component. The Groovy dynamic type system makes accessing its internal properties trivial after that.

/**
   * Start the animation and then ensure that changing the speed slider changes the delay.
   */
   @Test void testSpeedSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('speedSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..JXBusyLabelDemoModel.SPEED_MAX - 1).each { speed ->
       slider.slideTo(speed)
       Assert.assertEquals(busyLabel.delay, speed)
     }
   }

  /**
   * Start the animation and then ensure that changing the points slider changes the
   * number of points.
   */
   @Test void testPointsSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('slider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..50).each { points ->
       slider.slideTo(points)
       Assert.assertEquals(busyLabel.busyPainter.points, points)
     }
   }

  /**
   * Start the animation and then ensure that changing the trail slider changes
   * the trailLength.
   */
   @Test void testTrailSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('tSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..20).each { trailLength ->
       slider.slideTo(trailLength)
       Assert.assertEquals(busyLabel.busyPainter.trailLength, trailLength)
     }
   }

It’s particular amusing to note that the test code is more verbose than the Swing component setup. Man, after all of the Swing code I’ve written, WHY WAS NONE OF IT EVER THIS EASY!
Sorry for the shouting, but it’s late and updating this code to use binding instead of change listeners AND writing the tests AND writing this blog post took all of about 45 minutes. So you’ll have to forgive me for getting excited and all.

Here is the promised video showing the FEST test suite being run.. Give it a second as the first round of tests(not shown in the code above) do a bunch of assertions to make sure that all of the expected Components can be found. Not terribly interesting to watch, but a great win for Java GUI testing!

Related posts:

1. More Groovy/Griffon/FEST Testing
2. SwingX busy label demo in Griffon and Groovy
3. SwingSet on Griffon

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