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:

Toggle Line Numbers

1 class UserListController {  2       3     static name = "userControl"  4     static scope = "session"  5       6     public static void initialize (binding) {  7         binding.SelectItems("userList") { ["Bob","Bill","Barbara"] }  8     }  9       10 }

From the example above you can see there are few 'settings' and other things of interest.

1. You can set the context variable name for the controller
2. You can set the scope of the controller
3. 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 scope.

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().

Reloadability

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.