RE: Suggestions for onentry/onexit tags

I agree with David quite strongly that for "non-instant" actions invoke is the way to go, and that mid statemachine derefercing to src (at least outside send/invoke) is best avoided where possible.

The multiple handlers currently in the specification is more forgiving if you allow xinclude or other preprocessing tricks to combine of states and handlers (or even the useful but old school copy/paste method of combination).  The semantics to an interpreter are clearly specified and a human reader/writer should be able to understand what multiple onentry/onexit handlers mean and do.  Multiple handlers (or "listeners") is also something other systems support (like DOM 3 eventing), even if the bubble, target, capture algorithm is different than the statechart/state machine algorithm present in SCXML.

From: David Junger [mailto:tffy@free.fr]
Sent: Tuesday, January 28, 2014 9:11 AM
To: Voice Public List
Subject: Re: Suggestions for onentry/onexit tags

Le 28 jan 2014 à 14:16, Andreas Gansen <c64zottel@gmail.com<mailto:c64zottel@gmail.com>> a écrit :


<action paralell="1" >
<action paralell="3" >
All actions with parallel 1 can be run simultaneously, while 1 runs before 3.
In times of multicores a valuable feature.

Actions should always be very quick. It's the way SCs are designed. If a long process (or a dozen, or a hundred) should be run, use <invoke> instead, or actions that start a process but return immediately. In fact, <invoke> is quite good for managing multiple child processes, and you can easily add custom parameters to specify process priority. Look into it.

>There are standard ways to do templating in XML. I think it would be better to reuse those for interpreters that wish to support such things.

I can't see the template pattern here. It is more a catalogue of functions which can be referenced.
But I am sure it can be reconstructed with xml.

Well, executable content in SCXML is made of XML, not functions, so if you want to make it reuseable you need to reference an XML structure somehow...

Having the code blocks outsourced would be an optional feature to share between applications/statecharts. Hence it could also be used to reduce bandwith usage of you see it as a library.

... On the other hand, if you are only using scripts for executable content, you can of course use <script src> which is already defined in the spec, or, even better when available, load libraries into the parent context before runing the SCs, and make them available to the SCs using interpreter-specific functionnality (e.g. passing a dictionnary of JavaScript objects to the SCxml constructor in JSSCxml: http://www.jsscxml.org/api.html#constructor).

                                    David