Re: Suggestions for onentry/onexit tags

Le 3 jan 2014 à 09:58, Andreas Gansen <c64zottel@gmail.com> a écrit :

> We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

As far as I know, there is one semantic feature of multiple onentry/onexit blocks: when an error occurs during execution of an executable block, the whole block's execution is aborted, but not the other executable blocks in the same state. You don't see what error has happened (for that, you need a transition with event="error.*", which will catch the error later), but it allows you to isolate "risky" executable content if the rest of the content doesn't depend on the success of previous blocks.

There is also a language design feature: authors don't automatically need to check for a previous handler in a big state when they write an onentry/onexit handler. It's good for modularity and collaborative editing. It also adds to expressivity: separate blocks are a good indication that the code inside is somewhat independent.

> Would it not be better to have 0 or 1 occurrence?

As far as I can see, the only advantage of having a maximum of one onentry and one onexit block would be to shorten or remove a very cheap iteration.

> How can I exit a state multiple times without re-enterring before?

When you re-enter a state, you must always run its onexit block(s) during the exit phase and its onentry block(s) during the entry phase of the microstep. That would be true even with your proposed modification.
If your implementation exits a state multiple times during one microstep, it's incorrect, and onexit blocks are the least of your worries.

> Please note either way:
> The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
>  considers one entry of onentry/onexit tags only.
> While the schema does not:
> http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd


I'm pretty sure the correct meaning is zero or more.

			David

Received on Sunday, 5 January 2014 23:44:00 UTC