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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
