You can handle workflow with 2 hidden form elements: step and action.
'step' is used to determine which step of the work flow the request was made
from. 'action' tells your action class which action the user wanted to
perform (not the same as a struts action class). Your action (struts) class
for the work flow will contain logic to determine what to do using the step
and action form properties.
It is considered, by many, a good design to use a single form bean and
single action class to handle the entire work flow.
For each HTML form, you will have a set of buttons: back, next, cancel, and
possibly others. Each button will set the value of the 'action' hidden form
element when it is pushed (via javascript). The 'step' form element is
static for each page.
The logic to handle the flow can be embedded within the struts action class
or factored into helper classes that will be instantiated and called when
the appropriate 'step' is reached
Thanks,
James Hicks
-----Original Message-----
From: Jeff Jensen [mailto:jeffjensen@(protected)]
Sent: Monday, July 07, 2003 1:26 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Workflow logic handling and "go back" handling
Hi,
We are starting to design a new web app that has lots of workflow logic. We
are using Struts for the controller and front flow control. We have the
option
to use most any J2EE technology.
The workflow logic is complex. The system involves many screens of
user input, and the screens presented change depending on user-entered
choices.
The decision-logic for "where to go next" not only involves the data from
the
screen just visited, but often also from prior screens.
None of us have experience with a larger and more complex decision tree
logic
like this. A couple of us have done something on a much smaller scale, and
fear that ideas in that context do not apply/scale/work well in this one.
Another wrinkle is the requirement to allow the user to go back to previous
screens and change anything. This of course affects a lot of things,
including
how to determine what data to discard with a change by the user that affects
the decision tree/screens presented.
So, besides "put the logic in session beans/facades", we need lots of advice
on
how to solve these two main problems!
Are there any patterns/pattern languages to consider? Are there any open
source libs/products to assist? Is there a good architecture for this to
minimize having a plethora of code in session beans to determine the next
view?
My guess is many teams must have already solved these problems; I know this
is
not "new"! Can anyone shed some light on best-practice solutions please?
I would appreciate any pointers and/or redirects to help solve the problem.
Thank you!
====================================================================
Community Web Site (Core J2EE Patterns Catalog - Online Version):
http://java.sun.com/blueprints/corej2eepatterns
Getting Started (Beta Version):
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
Get the book:
http://www.amazon.com/exec/obidos/ASIN/0130648841/corej2eepatte-20
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this email in error, please contact the sender and delete the material from
all computers.
====================================================================
Community Web Site (Core J2EE Patterns Catalog - Online Version):
http://java.sun.com/blueprints/corej2eepatterns
Getting Started (Beta Version):
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
Get the book:
http://www.amazon.com/exec/obidos/ASIN/0130648841/corej2eepatte-20
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
