On Thu, Jun 23, 2011 at 6:46 PM, Artem Vovk <vovk.ar...@googlemail.com> wrote: > 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 > <snip/>
Use history states (see mention in previous email). -Rahul > On Jun 23, 2011, at 11:54 PM, Rahul Akolkar wrote: > >> On Tue, Jun 21, 2011 at 3:42 PM, Artem Vovk <vovk.ar...@googlemail.com> >> 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: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
