Understanding Addons

Addons are a plugin's best friend. While plugins can only contribute build-time artifacts (such as scripts) and participate on build events, addons may contribute runtime artifacts (such as MVC Groups or services) and participate on application events.

Often times whenever you'd like to package a reusable runtime artifact you'd have to create an Addon as well.

Addon responsibilities

Addons may contribute any of the following to your application: MVC Groups and application event handlers. They can also contribute the following to the CompositeBuilder: factories, methods, properties and FactoryBuilderSupport delegates (attribute, preInstantiate, postInstantiate, postNodeCompletion).

Addons are created using a template that suggests all of the properties and methods you can use configure. The complete list follows:

Configuring Addons

This task is done automatically for you when you package an addon inside a plugin. The plugin's _Install and _Uninstall scripts will make sure that griffon-app/conf/Builder.groovy stays up to date. When you install a plugin that contains an addon you'll notice that Builder.groovy may get updated with a line similar to the next one

root.'CustomGriffonAddon'.addon=true

This means that all factories, methods and props defined on the Addon will be available to View scripts. However you need to explicitly specify which contributions should be made to other MVC members. You can list them one by one, or use a special group qualified by '*'. In recent releases of Griffon the default configuration is assumed meaning you won't see any changes in the Builder.groovy file. You can still apply modifications as explained below.

The following snippet shows how to configure an Addon to contribute all of its methods to Controllers, and all of its contributions to Models.

root.'CustomGriffonAddon'.controller='*:methods'
root.'CustomGriffonAddon'.model='*'

The special groups are: '*', '*:factories', '*:methods', '*:props'

Should you encounter a problem with duplicate node names you can change the default prefix (root) of the addon to something more suitable to your needs. All nodes contributed by the addon will now be accessible using that prefix. Here's an example

nx.'CustomGriffonAddon'.addon=true

Assuming CustomGriffonAddon is defined as follows

class CustomGriffonAddon {
    def factories = [
        button: com.acme.CustomButton
    ]
}

Then instances of CustomButtom can be obtained by using nxbutton, whereas regular instances of JButton will be accessible with button.