commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml] Target of transition as variable?
Date Fri, 24 Jun 2011 01:27:17 GMT
On Thu, Jun 23, 2011 at 6:46 PM, Artem Vovk <vovk.artem@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.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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message