Skip to end of metadata
Go to start of metadata

Overview

Griffon 0.9.1 – "Aquila heliaca" - is a maintenance release of Griffon 0.9.

New Features

Builtime

Default imports

Starting with this release default imports per artifacts are supported. All Groovy based artifacts will resolve classes from the griffon.core and griffon.util packages automatically, there is no longer a need to define imports on those classes unless you require an static import or define an alias. An example of this feature would be as follows.

griffon-app/controllers/MyController.groovy

The Metadata class is defined in package griffon.util.
There are additional imports per artifact type, here's the list of default definitions

  • Model
    • groovy.beans -> @Bindable, @Vetoable
    • griffon.beans -> @Listener
    • java.beans -> useful for all PropertyChange* classes
  • View
    • java.awt
    • java.awt.event
    • javax.swing
    • javax.swing.event
    • javax.swing.table
    • javax.swing.text
    • javax.swing.tree

The list of imports per artifacts can be tweaked or changed completely at will. You only need to specify a file named META-INF/griffon-default-imports.properties with the following format

These are the contents of the default file

Imports are cumulative, this means you can't remove a package from the default list provided by Griffon.

Non-Groovy Artifacts

Since the first Griffon release all artifacts defined under griffon-app/* must be written in Groovy. However in the true spirit of polyglot programming these restriction is no longer in place. The first additional language to be supported by artifacts is Java, other JVM languages will follow in the future. Non-Groovy artifacts must extend a particular class in order to receive all the benefits of a typical artifact. The default artifact templates can handle both Groovy and Java types.

For example, creating an application with the default MVC group using Java is as simple as

The fileType switch indicates that the templates must pick a Java based template first. If no suitable template is found then a Groovy based template will be used. The setting of this flag is saved in the application's build configuration, this way you don't need to specific the fileType switch again if your intention is to create another artifact of the same type. Of course you can specify the flag at any time with a different value.

This is the Controller code generated with the previous command

griffon-app/controllers/simple/SimpleController.java

This is the corresponding Model class

griffon-app/models/simple/SimpleModel.java

Finally, here's the View class

griffon-app/views/simple/SimpleView.java

Please note that the View class must make sure that the UI is built inside the EDT and that any window must be added to the current WindowManager. The generated Java based artifacts are functionally equivalent to their Groovy counterparts.

AST Injection

Related to the previous feature, the Griffon compiler will perform appropriate AST injections for common methods to all artifacts. A Groovy based Controller will automatically implement the GriffonController interface. This means the controller's contract will be visible to non-groovy artifacts. Similar rules are applied per artifact type.

Command line arguments passed to application

You can pass command line arguments to the application and access them by calling getStartupArgs(), this will return a copy of the args (if any) defined at the command line. Examples

Runtime

Artifact API

The Artifact API has been revamped and is now on par with Grails' Artifact API. You can now inspect and artifact and ask for its particular GriffonClass, which should give you detailed information on the artifact itself. For example, a Controller instance will return a GriffonControllerClass from which you can obtain a list of all available controller actions and event handlers. A GriffonModelClass returns a list of all properties and event handlers. GriffonServiceClass can return a list of all service methods and event handlers. You get the idea.

Sample Applications

Griffon 0.9.1 ships with 5 sample applications of varying levels of complexity demonstrating various parts of the framework. In order of complexity they are:

File Viewer

File View is a simple demonstration of creating new MVCGroups on the fly.

Source:

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

Font Picker

Font Picker demonstrates form based data binding to adjust the sample rendering of system fonts.

Source:

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

Greet

Greet, a full featured Griffon Application, is a Twitter client. It shows Joint Java/Groovy compilation, richer MVCGroup interactions, and network service based data delivery.

Source:

To run the sample from source, change into the source directory and run griffon run-webstart from the command prompt. Because Greet uses JNLP APIs for browser integration using run-app will prevent web links from working.

SwingPad

SwingPad, a full featured Griffon Application, is a scripting console for rendering Groovy SwingBuilder views.

  • No labels