commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ouyang, Landon - ES/RDR -Gil" <>
Subject RE: [SCXML] XML engine decoupled from code
Date Wed, 30 Apr 2008 22:00:11 GMT

Thanks once again for the quick response.

Before reading your e-mail I had already decided to go with the <invoke>
route for developing our implementation. I made our state machine class
an invoker class and registered it with the SCXML executor. The invoke()
method would trim the string passed in as the source parameter and
invoke the method similar to the AbstractStateMachine class. I am now
able to add statements in the XML that utilize the <invoke> tag to
invoke Java methods defined inside the state machine class.

I ran into a problem which leads me to believe I may have chosen the
wrong route: I cannot access the initiated values of the class! For
example, the state machine needed access to the GUI to change various
widgets. I had a member assigned to the JFrame to accomplish this but
this member is now null in the invoked method even though I correctly
initialized it earlier! This never happened before until I transformed
the state machine class to an invoker class. Is the Invoker object a
separate instance of the original state machine object?

Landon Ouyang
Member Technical Staff
ITT Electronics Systems, Radar Systems - Gilfillan
7821 Orion Ave,
Van Nuys, CA 91406
(818) 901-2982

-----Original Message-----
From: Rahul Akolkar []
Sent: Wednesday, April 30, 2008 11:15 AM
To: Commons Users List
Subject: Re: [SCXML] XML engine decoupled from code

On 4/29/08, Ouyang, Landon - ES/RDR -Gil <> wrote:
> Ingmar,
>  Thanks for the response. Our state machine maps states to specific
>  activities. It does not use a listener or a timer but rather a custom
>  class that utilizes an event stack for the firing of events within
>  state routines.
>  Your solution based on conditional transitions sounds like a
>  one. Given this information there are a couple more questions I have:
>  1) Is there a way to specify Java routines in the XML file to be
>  executed with the <onentry> tag? Possibly with <invoke>? We can then
>  away with invoking state routine/handlers that are implemented in our
>  class (similar to AbstractStateMachine).

Possible with either (<invoke> for long running semantics, custom
actions in <onentry> etc. for shorter routines).

Specifically to your <onentry> question, see:

For custom actions, map Java exceptions to logical outcomes (events)
rather than throwing them.

>  2) If the answer to question 1 is true, can we fire events within
>  Java routines to determine the transitions within these states? If
>  we can forego your "cond" solution and instead use the Java routines
>  determine the paths our state machine takes.

There are two categories of events, external and internal / derived.
For custom actions, you can trigger derived events (add any events to
the derviedEvents collection in Action#execute(...) ).

If you must fire external events, then the semantics of <invoke> are
more suitable. Based on what I've read in this thread so far, I think
a custom action will do (and has a considerably simpler execution


>  Thanks!
>  Landon Ouyang
>  Member Technical Staff
>  ITT Electronics Systems, Radar Systems - Gilfillan
>  7821 Orion Ave,
>  Van Nuys, CA 91406
>  (818) 901-2982
> -----Original Message-----
>  From: Ingmar Kliche []
>  Sent: Tuesday, April 29, 2008 1:16 PM
>  To: Commons Users List
>  Subject: Re: [SCXML] XML engine decoupled from code
>  Landon,
>  I'm not sure if your CheckRotation is really a state. To me it sounds
>  more
>  like a guard condition (i.e. a condition) to decide which state to
>  (e.g. the state machine is in state A and some event arrives - which
>  ? -
>  then check the guard condition and decide to go to B or C). Could you
>  elaborate a little on your state machine. What is the event which
>  is triggered? What drives your state machine? Is it a timer which
>  triggers
>  the engine on a regular basis? Or is it an external process that
>  events, or is it some user input, ...?
>  The information which you need to check (i.e. bRotating) seems to be
>  available in the container application (the one that embedds the
>  engine). Isn't it possible to pass this information (bRotating) along
>  with
>  the event (i.e. as payload of the event) into the engine (something
>  triggerEvent("???", bRotation))? In this case you could access
>  within the SCXML code:
>  <state id="A">
>    <transition event="???" cond="_eventdata.bRotation == true"
>  target="B"/>
>    <transition event="???" cond="_eventdata.bRotation == false"
>  target="C"/>
>  </state>
>  Or could you use a CustomAction to access bRotation?
>  There is certainly a solution for your problem, but it would help (at
>  least
>  me) if you could describe a little more (if possible).
>  Best,
>  Ingmar.
>  2008/4/29 Ouyang, Landon - ES/RDR -Gil <>:
>  > Hi,
>  >
>  > A conceptual issue has arisen after creating a working application
>  that
>  > uses the Commons SCXML engine.
>  >
>  > Based on what we want out of the engine, it is essentially
>  > that the code implementation (Java) is decoupled/independent of the
>  > underlying engine (XML file).
>  >
>  > To illustrate the problems I encountered, here is an example: there
>  a
>  > state called CheckRotation that can detect whether there is or
isn't a
>  > rotation. We need the ability for a developer to be able to place
>  > state anywhere in the state machine (possibly multiple times) and
>  direct
>  > the state machine based on one of the two outcomes without having
>  > write any Java code; he should only have to edit the XML file. For
>  > example, one path could be A -> CheckRotation -> C or D and another
>  > could be E -> CheckRotation -> F or G.
>  >
>  > We can modify the Java code so the CheckRotation method could fire
>  > different events to direct the path.
>  >
>  > if(PrevState == A)
>  > {
>  >        if(bRotating)
>  >                fireEvent(EVENT_C);
>  >        else
>  >                fireEvent(EVENT_D);
>  > }
>  > else if(PrevState == E)
>  > {
>  >        if(bRotating)
>  >                fireEvent(EVENT_F);
>  >        else
>  >                fireEvent(EVENT_G);
>  > }
>  >
>  > But this solution adds complexity and defeats the whole purpose of
>  using
>  > the engine in the first place! The CheckRotation state would need
>  > multiple conditional transitions defined (instead of two) in the
>  > file and the Java code would be interlinked with the XML engine! Is
>  > there a more proper solution to this issue?
>  >
>  > --
>  > Landon Ouyang
>  > Member Technical Staff
>  > ITT Electronics Systems, Radar Systems - Gilfillan
>  > 7821 Orion Ave,
>  > Van Nuys, CA 91406
>  > (818) 901-2982
>  >

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

This e-mail and any files transmitted with it may be proprietary and are intended solely for
the use of the individual or entity to whom they are addressed. If you have received this
e-mail in error please notify the sender. Please note that any views or opinions presented
in this e-mail are solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments for the presence of
viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

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

View raw message