« SwingBuilder + LookAndFeel = Prettier Setup Code | Main | Real Life Requrements Analysis »

MVC Separation in SwingBuilder Using the build() method

There is actually a GUI related feature in Groovy 1.1-rc-2 that I haven't blogged about yet, and it's a good one. A new method build was added that allows the user to load other Groovy scripts as though they were part of the currently executing script.

Huh? you say. What's so exciting about that? I could go on about how I changed FactoryBuilderSupport to extend Binding instead of GroovyObjectSupport and how I did some MetaClass magic to expose the methods of the builder to the script itself. But that is not what's really important. What is notable is how this enables and facilitates pure MVC separation in Groovy code.

MVC separation? Some may think that this only something web frameworks espoused, mostly because breaking MVC takes more effort that it is worth. However, Swing is notorious for breaking MVC because it is almost more effort that it is worth to do a good clean MVC separation, at the file level.

This is best illustrated by example. Consider one of our examples, the Groovy Regex Coach. It's got fairly good MVC separation to begin with. The existing good MVC separation is why I use it as an example, because when you separate out the view into another file, the controller logic is still sound. The principal difference being that at line 17 all of the view markup has been replaced with the call we use to load the view:

def gui = swing.build(RegexCoachView)

That's a fairly simple example, but more interesting is the changes I was able to do to the Console. The RC cycle is a very bad time to do major refactoring to a user facing component, so I did my experementing in the SwingXBuilder demos area. It's by no means a textbook example of MVC, but it does show off loading the view at the top level (lines 47 and 50) and then calling build() within the context of an existing build (lines 49-55). For extra credit I even used the variant where we compile a script at runtime to deal with MacOS specific classes (lines 59-84).

So yes we here at the Groovy project do eat our own dog food, and if I owned a dog I'd feed him sirloin and pizza too. I wish I was more the master of prose to communicate how big a deal I feel this is, but I'll just say that it is a big deal.


This page contains a single entry from the blog posted on November 7, 2007 12:09 PM.

The previous post in this blog was SwingBuilder + LookAndFeel = Prettier Setup Code.

The next post in this blog is Real Life Requrements Analysis.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33