commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml] StopWatch usecase and State pattern
Date Sat, 21 Aug 2010 17:47:31 GMT
2010/8/21 Thiébault Benoît <>:
> Hi everyone,
> I'm starting using SCXML and there is something that I am not sure to understand very
well. In the previous applications I developed, I used an event-driven architecture : my user
interface (for instance) was triggering Events that an EventDispatcher converted into (a)
Action call(s). The mapping Event/Action(s) was declared in a separate XML file. When I discovered
SCXML I thought I could improve this architecture by declaring the Event/Action(s) mapping
in the SCXML file. There are however some points that are not very clear yet for me.
> In the State design pattern (, a state is
represented by a class while the actions are mapped with the methods (roughly). I though I
could thus map my events with a method of a given object.
> But when I look at the StopWatch use case, and especially the StopWatch class (,
the whole state machine is represented by the class and each state is mapped by the methods...
In this use case, I don't see how actions are handled.
> I mean if I have two events triggered targeting the same state, how can I handle both
events differently ? There could be two ways to go from a state A to a state B, for instance
in an application where you want to edit a text file, from the "ready" state (when the application
is ready to start) you could go to the "edit" state by opening an existing file or by creating
a new one. The targeted state is then the same, even though the way to reach it is different.
I don't know how to model this in SCXML.
> Can someone help ?

The AbstractStateMachine class is one simple pattern among many that
may be employed to use Commons SCXML [1], and is certainly very basic.
It does not implement the State pattern as described in the document
you point to. The State pattern itself has limitations (requiring a
flattened state machine), so even implementing that isn't a silver
bullet. As someone who wants to use the State pattern, please take a
look at the AbstractStateMachine class implementation and perform the
changes necessary to rather implement the State pattern instead.

The higher order bit is that SCXML as a language is more powerful that
any of these individual patterns.



> Thank you
> Ben

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message