-
Get a monthly update on best practices for delivering successful software.

I'm gathering as much as I can on Griffon and how people are using it. Some things you can translated from Grails, but not everything. So here, as a public service, is the first of many Griffon tutorial pointers.
Dabble->Scribble has a nice blog entry on including log4j logging in Griffon. My favorite part? One of his goals for logging is to "Filter out the cruft from Groovy's massive stacktraces." Amen.

Installing plugins in Griffon is pretty easy. You just type something like
% griffon install-plugin [plugin-name]
in your application's base directory and it does all the rest. The actual plugin stuff gets put in ~/.griffon/<version>/projects/<appname>/plugins. But what if you want to develop a plugin and don't want to have to reinstall with every little code and test change?
Well, Josh Reed has a nice blog post on exactly how to do that. I won't recap it here, just say that essentially you nuke the installed stuff under the .griffon directory and make a symbolic link to your plugin development directory.
There are just two things that are a little confusing about it.
griffon list-plugins?Well, the answer to the first question is simple. Simply package your plugin by going going to it's base directory and typing
% griffon package-plugin
to generate a zip file. You can then navigate to your application's base directory and type
% griffon install-plugin [path to plugin]/plugin-name-0.1.zip
all assuming that your plugin is version 0.1. After that you are good to go with Josh's original instructions.
As for the second question, I'm still spelunking through the gant scripts to figure that one out.
Topics: Griffon, Griffon Plugin Development, Groovy
![]()

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?
Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.
I'll make some more posts here as my thinking and experimenting evolves.

Time to answer some questions about Griffon:
There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

In the past, one of the nice things about web application development versus desktop development has been the proliferation of application development frameworks. Where desktop development pretty much gave you a set of GUI components and a few concepts like event driven programming and MVC, web frameworks, in particular the more recent ones such as Rails and Grails, gave you an application architecture into which you could implement your domain specific logic.
Lots of benefits accrued from this predefined structure, not the least of which was the ability to quickly understand the application based on a shared understanding of how applications using this framework were put together. In my experience of looking at desktop and web applications over the years, the web applications were better and more consistently designed than their desktop counterparts. Similar tries at desktop frameworks just never seemed to gain any traction (recall Scope, an app framework based on the HMVC pattern that died of neglect).
Now along comes Griffon, a desktop application framework modeled on (and sharing an architecture) with Grails. Griffon has a very similar controller, view and model breakdown as Grails, and support for plugins. I'd like to see similar frameworks for .NET and Cocoa (yes, yes, Cocoa has some of it's own framework goodness, but could use some higher level application abstractions to make application development more consistent).