converted to 1.6 markup
|No differences found!|
Orchestra Dialog, PageFlow
A page "flow" is simply a sequence of pages that achieve some logical task. Examples are "address lookup", "shopping cart checkout".
Orchestra already allows data to be grouped together into conversation objects, allowing the lifetime of groups of objects to be independently controlled. While this is enough for many use-cases, there are situations where a simple "flat" map of conversations with names is not sufficient.
And in addition, there are common issues about navigation between pages that need to be addressed when building a system that has "flows". The issues of navigation and data lifetime are actually tightly coupled, so it makes sense to deal with them together.
A real page-flow means:
- The system is aware where the flow has been started
- The conversations are separated by flows too (not only the already existing window-conversation-context)
- The system is aware when the flow has been left, be it intentional or by clicking on a link outside of the current page-flow
Orchestra has been already extended so that a flow implementation should be able to configure Orchestra accordingly (nested conversation contexts are now implemented). We should now look at the second part of this issue - providing a page navigation system that handles orchestra conversation context creation/deletion at the appropriate times.
In the manner of Orchestra, a simple JSF-a-like solution should be found. It should build *on* the foundations of JSF as much as possible, rather than creating its own frameworks and concepts. And it should be possible to incrementally introduce it into existing applications rather than forcing webapps to be built around Orchestra.
More Detailed Requirements
- Want to navigate to a URL, then at some point "go back to calling view".
- Want beans required by the called flow to live in their own orchestra conversation, so that ending the flow discards flow-related objects. And in particular, whe a flow is cancelled (eg click on "cancel" button), no bean which existed before the flow was called should have been modified.
- Want orchestra access-scoped conversations to not be flushed until a called flow ends.
- Need to handle random navigation by user:
- for non-modal flows, cause flow resources to be discarded if the user abandons the current flow and goes somewhere else (eg via a top-level menu)
- for modal flows, leave resources active until they actually close that modal window.
- Allow a flow to start even when there are validation errors on the current page; starting a flow to look up an address or similar shouldn't require all data on the field to be valid. And when the flow ends and the calling page is redisplayed, user data that did not validate still needs to be present.
- Ideally, backing beans and pages should not have to be specially written to be part of a flow. It should be easy to make existing pages callable as part of a flow.
- Want to expose input data to the backing beans for the flow, and read back data from the flow when the flow was successful.
The orchestra flow project home page can be found at http://myfaces.apache.org/orchestra/myfaces-orchestra-flow/
As at 2008-10-24, Orchestra Flow (v0.0.1-SNAPSHOT) now implements all of the above requirements.
The internal implementation is currently a little ugly in places; any ideas on how to more elegantly implement those parts are welcome. But it works.
At ops.co.at we are currently working on integrating orchestra flow into our web applications.
Page OrchestraDialogPageFlowDesign2 was used as a guide when creating the current implementation. It may be slightly out-of-date; the information on the flow website should be the primary reference.
Notes from the initial discussions held when the Orchestra Flow project was started can be found at OrchestraDialogPageFlowDesign1. This is mostly of historical interest only.