commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artem Vovk <>
Subject Re: [scxml] Target of transition as variable?
Date Thu, 23 Jun 2011 22:46:14 GMT
Thanks for the answer! I have also implemented on this way, but I think it makes all complicated
and I see no benefits from static states
I give an example where dyn states are useful and much less verbose:

I have 10 basic_states that under some condition(internet is not available) can be transitioned
to another special_state(NoInternetConnection), but this state must know the basic_state from
which it receives the event, to go back under another condition(internet is available). With
dynamic states it takes only one assign per basic_state and one transition in special_state
and I does not need to change special_state each time when I want to add a new basic_state

On Jun 23, 2011, at 11:54 PM, Rahul Akolkar wrote:

> On Tue, Jun 21, 2011 at 3:42 PM, Artem Vovk <> wrote:
>> Can I use dynamic transition targets? Something like this?
>> <datamodel>
>>        <data id="dyn_state" expr="State1">
>> </datamodel>
>> ...
>> <transition  ... target="dyn_state"/>
>> If I use it on this way, I receive an exception: Transition target with ID "dyn_state"
not found -> Interpreter thinks that it is a name of the state, but not the variable...
Is there a way to define such transitions?
> <snip/>
> Not directly as you are illustrating above. Most state machines in
> general, and SCXML in particular, requires you specify fixed target(s)
> for each transition. This is actually quite useful because it allows
> static analysis to determine whether all transition targets are legal
> even before the state machine is executed. It is also not as limiting
> as it may seem at first, because of the existence of things like guard
> conditions on transitions and history states.
> For the above, a literal translation may appear to be as follows
> (replacing dynamic target with static ones):
>  <transition  cond="dyn_state eq 'State1'" target="State1"/>
>  <transition  cond="dyn_state eq 'State2'" target="State2"/>
>  ...
> The above pattern can certainly be used, and may seem more verbose.
> But note that there are usually two <assign> or similar statements
> elsewhere that are updating the data 'dyn_state'. Often, these can
> instead be replaced as appropriate guard conditions on the two
> transitions above so the net effect is no change in verbosity.
> -Rahul
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message