Here's another peek at some of the features available in Griffon 0.9.1 (last post showed how non-Groovy artifacts can be created). The Artifact API received a full face lift in the latest release, allowing you to query artifacts and their conventions in a similar way as it is done in Grails. If you've looked at Griffon's runtime API you might have noticed a good number of new interfaces, for example

• GriffonArtifact
• GriffonMvcArtifact
• GriffonModel
• GriffonView
• GriffonController
• GriffonService

These define the basic types of artifacts you may encounter on a vanilla Griffon application. Additional artifacts types may be introduced by plugins/addons. Useful as they are to determine how an artifact works, these interfaces cannot tell you what an artifact may contain, for example you can't inspect a Controller instance in order to find out which actions it exposes. This is where the next set of classes come in

• GriffonClass
• GriffonModelClass
• GriffonViewClass
• GriffonControllerClass
• GriffonServiceClass

Evey artifact instance is backed by its corresponding GriffonClass. This means that a controller instance of type FooController will have a GriffonClass of type GriffonControllerClass that can be used to evaluate the conventions set by the class FooController. Confused? don't be. Let's explore the Artifact API with an example.

Assume for a moment we need to create a form based application. Each form may have a variable number of attributes (for simplicity's sake let's keep them of type String at the moment). Also, each form may have their own set of actions that affect the data somehow. How should we tackle this problem? I heard someone said "code generation!". Yes, that's one way to do it, but you can paint yourself into an ugly corner pretty fast. Let's follow a different path. In the end we want an application that looks like this

When you click the Submit button you should get a dialog like the following one

Alright, let's see how a typical Model would look like
package latte import groovy.beans.Bindable class LatteModel { @Bindable String firstName @Bindable String lastName @Bindable String address }
Nothing unusual here, just your standard observable Groovy bean. Next is the Controller. Here we'll find the first hint that some magic will happen under the covers
package latte import griffon.util.GriffonNameUtils as GNU class LatteController { def model def clear = { model.griffonClass.propertyNames.each { name -> model[name] = '' } } def submit = { List values = [] model.griffonClass.propertyNames.each { name -> values << "${GNU.getNaturalName(name)} = ${model[name]}" } javax.swing.JOptionPane.showMessageDialog( app.windowManager.windows[0], values.join('\n') ) } }
This Controller exposes two actions: clear and submit. The job of the clear action is to reset the model state; it's done by simply setting each property value to an empty String. How does the Controller knows which properties must be reset? This is where the GriffonClass of the Model comes into play. The submit action uses the same trick (querying the Model's GriffonClass) to find out which properties must be read, then prepares and popups a dialog that displays all the information read from the Model. And now for the last part, let's have a look at the View
package latte import griffon.util.GriffonNameUtils as GNU application(title: 'latte', pack: true, locationByPlatform:true, iconImage: imageIcon('/griffon-icon-48x48.png').image, iconImages: [imageIcon('/griffon-icon-48x48.png').image, imageIcon('/griffon-icon-32x32.png').image, imageIcon('/griffon-icon-16x16.png').image]) { borderLayout() panel(constraints: CENTER, border: titledBorder(title: 'Person')) { migLayout() model.griffonClass.propertyNames.each { name -> label(GNU.getNaturalName(name), constraints: 'left') textField(columns: 20, constraints: 'growx, wrap', text: bind(name, target: model, mutual: true)) } } panel(constraints: EAST, border: titledBorder(title: 'Actions')) { migLayout() controller.griffonClass.actionNames.each { name -> button(GNU.getNaturalName(name), actionPerformed: controller."$name", constraints: 'growx, wrap') } } }
The View uses the same trick to access the Model's properties. It follows a similar path to find out which actions can be called from the Controller. The rest of the code is your standard Swing DSL

Now, what was that about multiple forms? The View as it stands is quite reusable, as it does not have ties to an specific Model or Controller class; you can actually share it with other Models and Controllers. Setting up multiple MVC groups can be done in griffon-app/conf/Application.groovy, assuming we have another form whose model is ExpressoModel then configuring it with this View and Controller is done in the following way
mvcGroups { // MVC Group for "latte" 'latte' { model = 'latte.LatteModel' controller = 'latte.LatteController' view = 'latte.LatteView' } // MVC Group for "expresso" 'expresso' { model = 'latte.ExpressoModel' controller = 'latte.LatteController' view = 'latte.LatteView' } }
We could have changed the Controller to another class if the clear and submit actions are not suitable for the new Model.

The new Artifact API is the first step on getting scaffolded models and views (perhaps even domain classes) working in Griffon. The rest of the code can be written as a set of plugins. Nick Zhu has written a validation plugin that will surely come in handy in getting the equation right.

Keep on Groovying!