Reference data is extra data that is needed by a form. Typically this is stuff like the options in a select, things that are not provided by the form backing bean.

3. ReferenceDataActions

In order to create a maintable, centralised pool of reference data, I recommend to use the following guidelines:

• Create a MultiAction called ReferenceDataActions.
• Create for each backing bean (or each class of backing bean) an initXXX, where XXX is the class of the backing bean.
• Create for each type of reference data a private method, that returns void. In the private method you put only 1 list or object onto the context. Call the methods something like putYYY, where YYY is the name of the class of reference data you are putting on.
• In the initXXX methods, you delegate to the private methods the types you need.

Take a look at following example:

public Event initCustomer(RequestContext context) {
putCustomerTypes(context);
putCountries(context);
return success();
}
public void putCountries(RequestContext context) {
context.getRequestScope().put(//INSERT CODE HERE
}

This way of defining the actions will give you an enormous amount of flexibility and maintainability.
When designing your application, you will need to ask yourself: What if something changes?

What if I need to put something new onto the context as referenceData? You just add the method to the initXXX method.
What if I need to change to source of a referenceData? You can just change the putYYY method.

Keeping referenceData out of your real Action classes, is great to keep those classes as small as possible.
The ReferenceDataActions class can grow quite big, but thats ok! Since the implementation inside the class is kept to a bare minimum (referenceData hardly ever needs logic), the class is not overcomplicated. Exposing only the init methods forces you to utilise only the methods you have control over, which you can alter without changing the API.

But as always, I’m open to discussion!

2. Go For Fail-Fast

Spring WebFlow makes use of ParameterMap to represent the state of the scope’s. They could easily just exposed a Map interface.

ParameterMap’s gives us neat getRequiredXXX methods that let’s us implement Fail-Fast easily. If you rely on a certain object to be in the scope, you should use these methods instead of the normal ones. The getRequiredXXX will throw IllegalArgumentException when the object was not found. This is a far better representation of the error, then a NPE a couple of lines down. Sometimes you don’t really act on the object, but pass it on to let’s say your DAO layer where the exception could be a lot more obscure.

Fail-Fast is a design method that could be incorporated in nearly any method/class. An excellent read about this can be found here.

Last couple of months I have been developing in Spring Webflow intensively. During this time, I’ve made some newbie mistakes that I believe are happening quite frequently. So in my brand new blog, I’m addressing some of the common bad practices I have encountered.

Let’s dive into the first one, the others will follow shortly!

1. Prefer RequestScope

First some background:
As you need to know, Spring WebFlow 1.0 has 4 scopes.

• ConversationScope: objects are kept for the duration of the flow, including any subflows.
• FlowScope: objects are kept for the duration of the flow, excluding subflows.
• FlashScope: objects are kept for the duration request. When haven redirects enabled (standard behavior on webflow), the objects are keps for the duration of the redirect as well.
• And finally RequestScope: objects are placed for the duration of the request (not surviving the redirect if any).

Since the duration of the first 3 scopes is undetermined, WebFlow serializes the objects that are saved on the scope. Serialisation is a relative expensive process of saving the object to an ObjectOutputStream. On accessing the scope, the object needs to be deserialised.

FlashScoped objects can in many cases be placed in a RequestScope, which provides much better performance.

When to use FlashScope

In fact, FlashScope should only be used when you want to pass objects into the view layer of the next viewState. This is the only time the object needs to survive the redirect.

FlashScope is often abused by using it in the entry-action of a viewState. Any objects that were placed as FlashScoped objects could be placed without much fuzz on the RequestScope. The action that invoked the code, should then be placed in the render action. Et Voila, the code has been optimised.

Conclusion: Always use RequestScope if possible.