Experiencing Spring WebFlow, part I

Howdy!

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.