Re: Suggestions for onentry/onexit tags

Hi,

Hm, I viewed it more in sense of a function call, but it is actually
an ordered list of handlers. Now I see also the flexibility through
Chapters 4 and 5, which makes it possible to construct easily my
function-like interpretation by using <script src..>

@David: Thanks for your Master-Thesis. Is your performance test setup
somewhere online?

I really appreciate your help.

Tusen takk,

Andreas




On 28 January 2014 21:08, Michael Bodell <[email protected]> wrote:
> 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:[email protected]]
> 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 <[email protected]> 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