Bringing Java to Griffon

If you're an avid reader of DZone feeds chances are you noticed that Griffon 0.9.1 was released last week. This release brings a good number of fixes and features. One particular feature will let you use Java as your language of choice for writing any MVC member (if not all). This opens the door for reusing legacy code in a more convenient way. Let's look at a simple example. First, make sure you have the latest Griffon release installed and configured, then type the following on your command prompt:

griffon create-app mocha -fileType=java

Why pick mocha as the name? because it's a delicious (and groovier) Java brew

This command will create a brand new application for us. Mind the fileType configuration flag. This will instruct the creation script to look for MVC templates that match a particular file extension, in our case Java. In the event that no matching template is found then the Groovy version will be used. If you inspect the contents of the newly created application you'll notice the following files

griffon-app/models/mocha/MochaModel.java
griffon-app/views/mocha/MochaView.java
griffon-app/controllers/mocha/MochaController.java

Good. Let's continue this exercise by modifying the Model and Controllers first. We'll make sure that the Model contains at least one observable property, while the controller will have a single action that pops up a MessageDialog upon activation. The contents of the dialog will be whatever value is currently assigned to the model's observable property. Edit the Model file. You'll see that the template already suggests you the code needed to setup an observable property named input. Removing the comments leaves us with the following code

The AbstractGriffonModel supplies the basic behavior for a GriffonModel implementation. Next is the Controller. Its template also suggests how an action can be implemented.

Three things to note here. First, the Controller requires a reference to its Model, that's why a setter of the appropiate type must be added to the class. Second, the action itself is implemented as a method given that Java knows nothing of Groovy's closures. By the way, this trick also works on Groovy based controllers. Finally, this class also extends from an abstract one that delivers default behavior, for example the getApp() method used to get a hold of the current application instance. And now for the piece de ressistance: writing a Java based View. Fortunately for us the template does most of the work once more. A Java based View must have a reference to its Model and Controller. It should also initialize the UI inside the Event Dispatch Thread. Lastly, it should connect UI elements with the model by means of traditional event listeners or a binding library. For this example we'll assume that the View is just a mediator between the application and a standard Java view built by conventional means.

package mocha;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import java.util.Map;

import griffon.swing.SwingGriffonApplication;
import griffon.swing.WindowManager;
import org.codehaus.griffon.runtime.core.AbstractGriffonView;

public class MochaView extends AbstractGriffonView {
    private MochaController controller;
    private MochaModel model;

public void setController(MochaController controller) {
        this.controller = controller;
    }

public void setModel(MochaModel model) {
        this.model = model;
    }

public void mvcGroupInit(Map<String, ?> args) {
        execSync(new Runnable() {
            public void run() {
                JFrame view = new JFrame("mocha");
                view.setIconImage(getImage("/griffon-icon-48x48.png"));
                view.setIconImages(java.util.Arrays.asList(
                    getImage("/griffon-icon-48x48.png"),
                    getImage("/griffon-icon-32x32.png"),
                    getImage("/griffon-icon-16x16.png")
                ));
                view.setLocationByPlatform(true);
                view.getContentPane().add(init());
                view.pack();
                ((SwingGriffonApplication) getApp()).getWindowManager().attach(view);
            }
        });
    }

// build the UI
    private JComponent init() {
        MochaPanel panel = new MochaPanel();
        final JTextField input = panel.getInput();
        input.getDocument().addDocumentListener(new DocumentListener() {
            public void changedUpdate(DocumentEvent e) { model.setInput(input.getText()); }
            public void insertUpdate(DocumentEvent e)  { model.setInput(input.getText()); }
            public void removeUpdate(DocumentEvent e)  { model.setInput(input.getText()); }
        });
        panel.getOkButton().addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                controller.show(e);
            }
        });
        
        return panel;
    }

private Image getImage(String path) {
        return Toolkit.getDefaultToolkit().getImage(MochaView.class.getResource(path));
    }
}

We can appreciate that the View does ensure that the UI is initialized inside the Event Dispatch Thread, as the init() method is called within the boundaries of a call to execSync(). Exactly, the same method you have access in Groovy artifacts. The init() method creates an instance of MochaPanel and associates some of its components with the model, in other words, performs old-school binding on them. There's one last source file we nee to look at, the MochaPanel. For this example I've chosen to duplicate Example #4 from the DesignGridLayout examples, slightly modified to include a JTextField and a reference to the "OK" button:

package mocha;

import java.awt.*;
import javax.swing.*;

import net.java.dev.designgridlayout.DesignGridLayout;

public class MochaPanel extends JPanel {
    private JTextField input;
    private JButton okButton;

public MochaPanel() {
        init();
    }

public JTextField getInput() { return input; }
    public JButton getOkButton() { return okButton; }

private void init() {
        input = new JTextField();
        okButton = new JButton("OK");

DesignGridLayout layout = new DesignGridLayout(this);
        layout.row().grid(label(0)).add(input);
        layout.row().grid(label(1)).add(button()).add(button());
        layout.row().grid(label(2)).add(button()).add(button()).add(button());
        layout.row().grid(label(3)).add(button(), 2).add(button());
        layout.row().grid(label(4)).add(button()).add(button()).add(button()).empty();
        layout.emptyRow();
        layout.row().right().add(new JButton("Cancel")).add(okButton);
    }

private static JLabel label(int index) { return new JLabel("Row "+index); }
    private static JButton button() { return new JButton("Button"); }
}

This class stands for your run-of-the-mill Java View. We're almost ready to launch this puppy, we're only missing the DesignGridLayout library in our classpath. That can be solved easily by just installing a plugin

griffon install-plugin designgridlayout

You should see a similar screen when you run the application and enter some text in the text field

Once you click on the "OK" button you're greeted with a dialog

And that's all that there's too it. By the way, your choice of fileType will be saved in griffon-app/conf/BuildConfig.groovy so that further artifacts can be created with the same type without the need to specify the same flag over and over again. You can of course, change this behavior by editing the file or setting the flag once more. Assuming you'd like to create a Groovy service for this application you'd only need to type

griffon create-service accounts -fileType=groovy

More Griffon 0.9.1 feature discussions to come later

Keep on Groovying!

NOTE: on Windows platforms you're required to surround -fileType=java with quotes. This is a know issue (GRIFFON-265) whose fix will be available in the next release.

Posted by: Andres Almiray on November 1, 2010

About Andres Almiray

Why Attend the NFJS Tour?

Current Topics: