Topic: Griffon

Griffon Tutorials: Adding Useful Logging

groffon
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.

Topics: , , ,

Griffon Plugin Development: Some Nitty Gritty

groffon
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.

  1. How do you install a plugin in the first place so you can do the nuke and symbolic link thing in the first place?
  2. Why doesn't your plugin show up as installed when you run 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.

Griffon and a PureMVC Plugin: Some Initial Thoughts

puremvc-icongroffon

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.

Topics: , ,

Questions About Griffon

groffon

Time to answer some questions about Griffon:

  1. What is the size of the jar that gets generated for a Griffon jar?
    If you package it all up ('griffon package'), then a vanilla Griffon jar weighs in at 4.7M. That's mostly the Groovy runtime (4.4M) and the Griffon runtime (204k). If you're concerned about download size for Java Web Start, then you won't want to bundle it as a single jar, but rather let your users download the Groovy and Griffon runtimes once, then your app specific jar as it is updated.
  2. Can Griffon apps be distributed via Java Web Start?
    Yes. When you run 'griffon package', you get an executable jar, an applet, a JWS app and a 'zip' that is structured as a directory with bin and lib subdirs and batch and shell files to run the application. In short, most ways that you may want to deploy the application.

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.

Griffon: Convention over Configuration for the Desktop

groffon

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).

Continue reading »

Launch: Pathfinder Newsletter

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

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com