Alternatively, you can use one action form in session scope with a
series of actions representing each page. Each page in the wizard would
have a series of forward representing the transition links from that
state to others, basically modeling a FSM with actions as states and
forwards as transitions. This works well, with configuration of "next"
and "previous" being pushed out into the struts configuration file. If
you need the list of valid pages to transition to filtered, you can do
this with a little logic in a) the form, b) the action, or c) a tiles
controller that pre-processes the GET request for the form and
additively or subtractively controls which navigation paths are visible
on the page. I've done this several times entirely in struts for
different "wizard" flows. I've always wound up coding the state
transition guards in Java, which is why an alternative like Spring flow
might be even better.
Cheers,
Mike
------------------------------------------------------------------------
Michael Taylor
TXE Systems, Inc.
[EMAIL PROTECTED]
Abdullah Jibaly wrote:
I have not used it yet, but you may want to take a look at spring web flow, it
is designed for these 'wizard' scenarios, and supposedly integrates well with
struts.
If you want to use Struts components only, one suggestion:
1 big action
1 big action form
Several jsps
The jsp form always posts to the same action, which then figures out its state,
based on that validates the input, does its stuff and forwards to the right jsp.
-----Original Message-----
From: Clint Shank [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 22, 2005 4:18 PM
To: user@struts.apache.org
Subject: Navigation Problem
We have a struts app that gathers data screen by screen and then processes
the data at the end. On each screen is a previous and next button. The
possible screens in the workflow depend on certain state: what things the
user has chosen so far, the user's preferences and so on. My question is...
suppose the user is on a screen and hits next. He could go to one of many
screens depending on the state mentioned above. That is, some screens apply
and some don't. We're trying to think of an elegant solution, but for now,
we're thinking there is a nextFromScreenA kind of action that looks at the
state and figures out what to do and where to go next. Do you know of any
better solutions for this type of scenario?
Thanks,
Clint Shank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
