Two problems with this page: first, I mis-named the concept. It's really "Nested Web Navigation" that I'm describing. Second, the Spring guys have implemented the concepts herein as Spring Web Flow. Yay! I'm just keeping this page around as a record of my original ideas on the concept.
I wrote the below, which is basically a few design notes/thoughts about "hierarchical MVC", a few months before the Spring Web Flow project started delivering code. I have no involvement in that project, but from what I read about it, it seems to address most of what I've written here.
Hierarchical MVC (HMVC) is the ability to define navigation flows in Spring and to compose navigation flows from other navigation flows. This feature is most often needed in order to:
- Reuse navigation flows from different parts of a web application.
- Decompose navigation into "chunks" that are easier to control and understand.
Requirements to achieve HMVC:
- Decoupling of success view creation from Controller code.
- A way to describe directed graphs (Flows) of "Nodes". A Node represents a page or request. Note that "Nodes" are already there, sort-of -- they are the view definitions that Spring already has.
- A way to compose Flows. This is where the hierarchical part comes in.
- A way to track the current state of an HMVC interaction with a particular client, and a way to return to the proper Node when a given Node completes.
- The composite pattern comes to mind (obviously, since I've mentioned composition a couple of times already!). The composite is that of Nodes and Flows. A given Node in a Flow could be yet another Flow.
- There would need to be an external FlowManager? (or series of FlowManagers?, one for each Flow) to keep track of a given client's flow state. Perhaps this "flow state" would be called a FlowContext?.
- The common model for separating actual "next" steps is to have the Controller/Action?/whatever return a return code of some sort (BEA's webflow works this way). The return code is an indicator of the completion state of a give Node, of which there can be many. The FlowManager? knows what Node gets control next based on the return code.
- It seems as though the FlowManager? would live in the session. The current FlowContext? would be kept in a well-known variable on the session (or accessed via the FlowManager?), with the others waiting to be popped into place as sub FlowContexts? are exited. Controllers (Nodes) would be able to access flow-scoped data and methods in this fashion.