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 <vovk.artem@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
|