Even though it is nice to be able to define action closures and the like right inside
your view script, it becomes evident very quickly that you alot of times need the same
code in different view scripts. Of course, you can always use some type of backing bean,
which work perfectly fine. But what if you don't really want to use
those components, and you want a reloadable script that can contain backing bean methods
but that has all the power you already have in a Gracelet view script?
This reasoning has motivated the addition of Gracelet Controllers. They are named such
since they are intended to complement (or provide an alternative) to other types of
backing bean controllers in the MVC flow of things.
A needs to be a Groovy class. The location of a reloadable controller must be in the
WEB-INF/gracelet/controller directory of your web application and the name of the file must
end in Controller.groovy.
Lets say you have the need to get a list of users for many different
gracelet view scripts and thus you want to put this reusable and more manageable method inside
a controller. The following could be the source for your controller:
From the example above you can see there are few 'settings' and other things of interest.
You can set the context variable name for the controller
You can set the scope of the controller
You can provide an optional and static initialize(binding) method
If you do not provide a name via the static 'name' property, it will default to the file name
less the '.groovy'. If you do not specify the scope (yes using a string) it will default to the conversation
In the initialize(binding) method you are provided an object that can be used to access the variable contexts
and use closure factories in order to initialize DataModels, SelectItems and other Factory's. In other parts of
your script or class you will be provided with automatic variable resolution to the different scoped contexts. So you will not
need to qualify them with a binding variable like on the static initialize method().
These controllers are automatically reloadable just by changing the code. When the controllers are stored in the conversation
scope, the changes will not be seen until using a new conversation. You can learn more about how to use controllers in the
Using Controllers section of the tutorial.