Michael,
Thanks. Your solution was very interesting. It is very similar to what
I wound up building, although you took the time to generalize it and
write some great articles. One thing that I didn't like about my
previous attempts was dependence upon writing Java code to model the
transition rules and identify the current state. It appears from your
articles that your solution depends upon tight integration with the
application model. There are two down sides to this. The obvious one
is writing more code, where it might be generated from a model. The
other is that a tight coupling/merging of the FSM logic and the model
state would tend to lead to application models geared toward a single
FSM. If I were going for more re-usability I might like to have
multiple patterns of interaction that uses the same application model
objects. Have you considered combining an XML representation of the
state machine with something like EL expressions or XPath expressions
that perform the same logic in terms of the target model's state?
Having used iLogic's Rhapsody to model and generate real time process
control systems, I think that a case should/could be made for automating
the mechanical structure of the FSM implementation and isolating it from
the user input (identification of states, transitions, triggers and
guards). I think it could be built without any Java artifacts other
than the action class.
What are your thoughts on this? Which direction are you currently
moving in with your project?
Cheers,
Mike
------------------------------------------------------------------------
Michael Taylor
TXE Systems, Inc.
[EMAIL PROTECTED]
Michael Jouravlev wrote:
Just cannot help it; I am sorry, just cannot keep it inside ;) On the
other hand, maybe not everyone knows about it yet?
Homepage: http://www.superinterface.com/easywizard.htm
Live demo: http://www.superinterface.com/wizard/signupWizard.do
Now back to the regular programming (c) Frank ;-)
P.S. The source code on the website works ok, but I am preparing a new
version now, which is better integrated with Struts and with my
two-phase DialogAction class. It its current state it already handles
things like Back button and or view/model synchronization like nothing
else does. Word.
On 6/22/05, Michael Taylor <[EMAIL PROTECTED]> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
