A lot of the concepts are from Beehive Page Flow, but I'm being purposefully vague about the implementation details so we can choose a design that's clean and fits with the rest of the project.

See StrutsTi/ControllerMock for other controller features.

Basic State Management

Each page flow controller is itself a bean that is instantiated when a request is made for:

It contains state relevant to the navigational logic in the class. The basic rules are:


Key concept. A "nested" page flow is one that can be brought to life temporarily, with the intention of returning to the current page flow. A nested page flow controller is a controller that:

It alters the basic rules as follows:

Long-Lived Page Flows

There are some page flows that shouldn't be destroyed when other page flows are hit. These are marked with some sort of "long-lived" indicator. If you leave a long-lived page flow and then come back to it, you'll get the same instance of the controller.


To support portals and also browser frames and multiple browser windows, page flows can be "scoped" into named areas within whatever entity is handling storage (user session, database, etc.).


Since controllers are stateful, the framework should synchronize on action method invocations. In Beehive this happens automatically... anyone think it should be optional in Ti?


There should be some sort of mechanism to ensure that altered controller instances are replicated in a cluster.


Page flow controllers should be Serializable, and the framework should take care of reinitializing transient state when appropriate (maybe with a hook?).

StrutsTi/StateManagement (last edited 2009-09-20 23:11:51 by localhost)