5.2 The MVC Pattern - Reference Documentation
Authors: Andres Almiray
Version: 1.2.0
5.2 The MVC Pattern
All Griffon applications operate with a basic unit called the MVC group. An MVC group is comprised of 3 member parts: Models, Views and Controllers. However it is possible to add (or even remove) members from an MVC group by carefully choosing a suitable configuration.MVC groups configuration is setup inApplication.groovy
located inside griffon-app/conf
. This file holds an entry for every MVC group that the application has (not counting those provided by plugins/addons).Here's how a typical MVC group configuration looks likemvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' } }
model
and view
will be initialized before the controller
. Do not mistake initialization for instantiation, as initialization relies on calling mvcGroupInit on the group member.MVC group configurations accept a special key that defines additional configuration for that group, as it can be seen in the following snippetmvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' } // MVC Group for "foo" 'foo' { model = 'sample.FooModel' view = 'sample.FooView' controller = 'sample.FooController' config { key = 'bar' } } }
FooController
can reach the key defined in the configurationclass FooController { void mvcGroupInit(Map args) { println args.configuration.config.key } }
5.2.1 MVCGroupManager
This class is responsible for holding the configuration of all MVC groups no matter how they were defined, which can be either inApplication.groovy
or in an addon descriptor.During the startup sequence an instance of MVCGroupManager
will be created and initialized. Later the application will instruct this instance to create all startup groups as required. MVCGroupManager
has a handful set of methods that deal with MVC group configuration alone; however those that deal with group instantiation come in 3 versions, with 2 flavors each (one Groovy, the other Java friendly).Locating a group configuration is easily done by specifying the name you're interested in findingdef configuration = app.mvcGroupManager.findConfiguration('foo')
create
methoddef configuration = app.mvcGroupManager.findConfiguration('foo') def group1 = configuration.create('foo1') def group2 = configuration.create('foo2', [someKey: 'someValue']) // the following will make the group's id match its name def group3 = configuration.create() def group4 = configuration.create(someKey: 'someValue')
Config.groovy
griffon.mvcid.collision = 'warning' // accepted values are 'warning', 'exception' (default)
def g1 = app.mvcGroupManager.groups.foo1 def g2 = app.mvcGroupManager.findGroup('foo1') def g3 = app.mvcGroupManager.foo1 assert g1 == g2 assert g1 == g3
app.mvcGroupManager.models.each { model ->
// do something with model
}
5.2.2 MVCGroups and Configuration
Now that you know there are several ways to instantiate MVC groups we can go back to customizing them.The simples way is to pass in new values as part of the arguments map that mvcGroupInit receives, for exampledef group = app.mvcGroupManager.buildMVCGroup('foo', [key: 'foo'])
config
key that every MVC group configuration may have then you must instantiate the group in the following waydef configuration = app.mvcGroupManager.cloneMVCConfiguration('foo', [key: 'someValue']) def group = configuration.create()
create()
method.
5.2.3 Configuration Options
The following options are available to all MVC groups as long as you use theconfig
key.Disabling Lifecycle Events
Every MVC group triggers a few events during the span of its lifetime. These events will be sent to the event bus even if no component is interested in handling them. There may be times when you don't want these events to be placed in the event bus in order to speed up group creation/destruction. Use the following configuration to gain this effect:mvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' config { events { lifecycle = false } } } }
Disabling Instantiation Events
The Griffon runtime will trigger an event for every artifact it manages. As with the previous events this one will be sent to the event bus even if no component handles it. Skipping publication of this event may result in a slight increase of speed during group instantiation. Use the following configuration to gain this effect:mvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' config { events { instantiation = false } } } }
Disabling Destruction Events
This is the counterpart of theNewInstance
event. Skipping publication of this event may result in a slight increase of speed when a group or any artifact instance is destroyed. Use the following configuration to gain this effect:mvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' config { events { destruction = false } } } }
Disabling Controllers as Application Event Listeners
Controllers are registered as application event handlers by default when a group in instantiated. This makes it very convenient to have them react to events placed in the application's event bus. However you may want to avoid this automatic registration altogether, as it can lead to performance improvements. You can disable this feature with the following configuration:mvcGroups { // MVC Group for "sample" 'sample' { model = 'sample.SampleModel' view = 'sample.SampleView' controller = 'sample.SampleController' config { events { listener = false } } } }