You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Konstantin Piroumian <KP...@protek.com> on 2002/04/09 11:29:40 UTC

[FLOWMAP] Flow script

Hi, Uli!

Glad to see you back to Cocoon. 

So, here goes our approach to flow control.

1. The approach is quite simple: we have a component (Screen Flow
Controller) that is called through a set of actions from the sitemap.
Possible actions are the following (this is not the complete list): 

	- start a flow
	- process input for the current state
	- cancel flow

and some others that are related to the possibility to run multiple flows
for a single user (get list of flows, set active flow, etc.).

2. Interaction with ScreenFlowController is performed through a simple
interface method:

	handleEvent(Event event): State;

Event object contains the event name (type: START, INPUT, CANCEL, etc.) and
according data, that is gathered from the request (we perform mapping from
request parameters to value objects - JavaBeans).

State object contains current form id (we map it to real file name),
response data (value objects that contain the model data for the current
form) and some other information related to the state (in-process, finished,
etc.). We place value objects into request attributes then use them to
display the form with Struts' taglib (it's possible with Cocoon as well).

3. Typical usage scenario is the following:
	- on Start Flow request a flow controller is created then placed
into the user session
	- start event is sent (called handleEvent(event)) to controller with
script ID (assigned externally: from user request or sitemap/struts-config)
	-  when event handling returned the new state then control is
forwarded to the according handler (e.g.: <map:read src="{form}.jsp" />)

When user submit some data then InputAction is called and performed the
following:
	- current state is refreshed
	- an event is created
	- input parameters are mapped to value objects
	- event is sent to controller
	- new state is returned
	- control is forwarded to the according handler

4. So, as you see it's quite simple in usage. The most complex part is input
data mapping to JavaBeans, but it's now can be easily solved using Ivelin's
approach with Castor (or any other mapping tool). Another advantage of XML
usage in this case is that it will be quite easy to implement a visual tool
for flow editing, especially when direct EJB calls will be supported (this
will allow to reduce the number of custom actions used in the flow script).

5. In the attached customer_reg_new.xml file you'll find my working draft of
Customer Registration flow script. The real script is a little more complex
and differ in some tag names, but I hope you'll get the idea. I've also
attached a sample sitemap to show how it look like in Cocoon.

6. As a side note, I'd add that we had two implementations of
ScreenFlowController: a local class that is placed in session and called
like any other Cocoon components and the other is an EJB (a session bean)
that acts on the EJB container side. It is also planned to implement flow
script includes and forwards.

I am open for critics and comments.

--
Konstantin
_________________________________________
Konstantin Piroumian
Lead Developer
ICQ#: 2297575
* Work Tel#:  +7 095 795 0520 * 1288
* More ways to contact me <http://web.icq.com/wwp?Uin=2297575> 
i See more about me <http://kot-p.hotbox.ru/> 
_________________________________________