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:
addonInit
- called right after the addon has been loaded but before contributions are taken into account
addonPostInit
- called after all contributions haven been made
addonBuilderInit
- called before contributions to the CompositeBuilder are taken into account
addonBuilderPostInit
- called after all CompositeBuilder contributions haven been made
events
- Map of additional application event handlers
factories
- Map of additional node factories, added to CompositeBuilder
methods
- Map of additional methods, added to CompositeBuilder
props
- Map of additional methods, added to CompositeBuilder
attributeDelegates
- List of attributeDelegates (as Closures), added to CompositeBuilder
preInstantiateDelegates
- List of preInstantiateDelegates (as Closures), added to CompositeBuilder
postInstantiateDelegates
- List of postInstantiateDelegates (as Closures), added to CompositeBuilder
postNodeCompletionDelegates
- List of postNodeCompletionDelegates (as Closures), added to CompositeBuilder
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 oneroot.'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 examplenx.'CustomGriffonAddon'.addon=true
Assuming CustomGriffonAddon
is defined as followsclass 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
.