Skip to: Site menu | Main content

A Grails-like Rich Application Platform

Griffon 0.3-BETA-1 Print

Overview

Griffon 0.3-BETA-1 – "Leopardus tigrinus" - is the first beta of the upcoming fourth Griffon release. It includes several enhancements to the build system and runtime options.

Principal Features

Griffon 0.3-BETA-1 has been migrated to Groovy 1.7.0. You will be able to take advantage of anonymous inner class support, power asserts, significant speed improvements and other features & fixes that make 1.7.0 the best release so far.

Build System

Native Libraries Support

Starting with this release you'll be able to place platform specific jars and lib files (.dll, .so, etc) on specific places and the framework will take care of the rest. The following platforms are supported at the moment: linux, windows, macosx, solaris (all 32bit versions). Follow the next convention to take advantage of this feature:

1. create a dir inside $basedir/lib with a platform name, for example linux.

2. place all linux specific jars on that directory.

3. if native files are required then create a native subdir in lib/linux and place the files inside there.

You may configure as many of the supported platforms but only the current one (where you're developing on) will be used when running the application on development mode. Packaging the application however, will gather all platforms together. You may configure additional settings per platform when running on applet/webstart. See the following section.

Packaging

Tweaking the generated JNLP and applet HTML files is now possible via configuration, opening the door for platform specific updates and plugins alike. This release includes a new section on Config.groovy, reproduced here for your convenience

Each key/value pair on the props node will be mapped to a <property> under the general <resources> tag. The resources node only accepts children whose name match the supported platforms (as suggested on the snippet. Both jars and nativelibs must contain a list of jar archives (either relative or absolute), as per the JNLP file syntax. Notice that you can also set platform specific properties.

Applet parameters may be specified as well, they will be set on the applet's JNLP and HTML files.

Finally you can change the default width (240) and height (320) of the applet container during packaging by passing -appletWidth and -appletHeight flags to the griffon command.

Help

Continuing what was started on the 0.2.x series this release provides better descriptions when the help command is invoked on a core command. Additionally plugin scripts will also be available to the help command. A note to plugin authors: make sure to provide a suitable description for the default target on your scripts, this way the help command will be able to present it to the user.

Stats

The stats command can now generate additional output in 3 formats: text, html and xml. Specify any of [-txt, -html, -xml] when invoking the command to get the desired output. The output files will be placed at config.griffon.testing.reports.destDir or $basedir/target if the former is not specified.

Docs

It is now possible to skip the generation of docs while packaging. This is useful while doing plugin development as it cuts the time of packaging the plugin. Use the -nodoc flag on the command line.

Runtime

Artifacts API

The Artifacts API fills the need to determine what type of artifact an instance may be. Base artifacts are: Model, View, Controller and Service. All artifact metadata is available through the ArtifactManager, a convenient artifactManager property is added to all application instances. ArtifactManager provides methods to evaluate the conventions within the project and stores internally references to all classes within a GriffonApplication using the ArtifactInfo class. An ArtifactInfo represents a physical Griffon resource such as a controller or a service. For example to get all ArtifactInfo instances you can do:

There are a few "magic" properties that the ArtifactManager instance possesses that allow you to narrow the type of artifact you are interested in. For example if you only want to print the name of all controller artifacts you can do:

The dynamic method conventions are as follows:

  • *Artifacts - Retrieves all the artifacts for a particular artifact type. Example app.artifactManager.controllerArtifacts.
  • get*Artifact() - Retrieves a named artifact for a particular artifact type. Example app.artifactManager.getControllerArtifact("ExampleController")
  • is*Artifact() - Returns true if the given class is of the given artifact type. Example app.artifactManager.isControllerArtifact(ExampleController)
  • *Classes - Retrieves all the classes for a particular artifact type. Example app.artifactManager.controllerClasses.
  • is*Class() - Returns true if the given class is of the given artifact type. Example app.artifactManager.isControllerClass(ExampleController)

The ArtifactInfo interface itself provides a number of useful methods that allow you to further evaluate and work with the conventions. These include:

  • newInstance() - Creates a new instance of this class.
  • getName() - Returns the logical name of the class in the application without the trailing convention part if applicable
  • getSimpleName() - Returns the name of the class as a property name
  • geKlass() - Returns the artifact class
  • geDynamicProperties() - Returns a List of all properties that have been added dynamically to this artifact's klass, usually added by metaClass.
  • geAllProperties() - Returns a List of all properties related to this artifact's klass, excluding [class, metaClass].

Services

Services support is now provided from the get go. There is a new command, create-service, that creates a new service artifact following a simple template, it will also create a test for it. Services are injected automatically into other artifacts by following a naming convention.

griffon-app/services/FooService.groovy
griffon-app/controllers/BarController.groovy

Dependency Injection

Icon

While services will be injected by matching property names this doesn't mean Griffon sports a Dependency Injection solution on the core, you would need to install a plugin that does that. Fortunately there are a few options already: Guice and Spring.

Addons

The addon template now contains hints to all configurable options. Missing from the previous release were the FactorBuilderSupport delegates: attributeDelegate, preInstantiateDelegate, postInstantiateDelegate and postNodeCompletionDelegate.

There are 4 new application events related to addon initialization: global and local:

Global

  • LoadAddonsStart[app] - triggered before any addon is initialized
  • LoadAddonsEnd[app, addons] - triggered after all addons have been initialized. addons is a Map of <name, instance> pairs

Local

  • LoadAddonStart[name, addon, app] - triggered before an addon is initialized
  • LoadAddonEnd[name, addon, app] - triggered after the addon has been initialized

Threading

A new threading abstraction is available: griffon.util.UIThreadHelper. This class provides equivalent functionality as SwingBuilder's edt, doLater and doOutside; however it is not tied to Swing, which makes supporting other toolkits like SWT, Pivot and Gtk a reality. This also frees you from instantiating SwingBuilder, or keeping a reference to it, in order to take advantage of its threading features. UIThreadHelper is a singleton class, accessible from anywhere at any time. This is its contract for reference

Inspection

An application is now able to know in which mode (environment) it is running by querying griffon.util.Environment.getCurrent(). Similarly the application's metadata (or application.properties) is now accessible via griffon.util.Metadata.getCurrent().

Deprecations

griffon.util.IGriffonApplication -> griffon.core.GriffonApplication

griffon.util.GriffonApplicationHelper.invokeScriptInsideEDT -> griffon.util.GriffonApplicationHelper.invokeScriptInsideUIThread

Sample Applications

Griffon 0.3-BETA-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.

WebStart of Application

Source: git

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.

WebStart of Application

Source: git

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.

WebStart of Application

Source: git

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.

izpack installer

Source: git

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

Weather Widget

Weather Widget integrates with Weather Underground to give a local weather forecast widget. It demonstrates plugin integration and NetBeans Matisse integration with the generate-view-script

WebStart of Application

Source: git

To run the sample from source, change into the source directory and run griffon run-app from the command prompt. You will need to be connected to the internet or already have the macwidgets plugin installed.

0.3-BETA-1 Release Notes

com.atlassian.confluence.macro.MacroExecutionException: The JIRA server returned a trusted apps error: USER_UNKNOWN; Unknown User: {0}; ["confluenza"]

Beta 1 Released 07 Jan 2010 (Leopardus Tigrinus)