- From: David Junger <tffy@free.fr>
- Date: Tue, 28 Jan 2014 11:17:28 +0100
- To: Voice Public List <www-voice@w3.org>
Le 28 jan 2014 à 10:27, Andreas Gansen <c64zottel@gmail.com> a écrit : > Your reasoning is completely valid and understood. My only concern is the semantic about onexit/onentry. > Even if it is well defined in the current version, I can't deny that it is a bit unnatural to call a second onexit block > My suggestions to combine functionality and modularity would be as follows: > <onentry> > <action> Code of the first onentry block </action> > <action> ... 2nd entry block </action> > </onentry> So… it's like multiple <onentry> but with extra tags inside? It might be useful for <transition>s where only one executable block is allowed… > Variation: > Define actions in LLCA (or separate file for re-usage): > <actions> > <action id="a1"> Codeblock </action> > <action id="a2"> Codeblock </action> > </actions> > > We just reference to the actions: > <onentry> > <action id="a1" /> > <action id="a2" /> > </onentry> 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. As for storing actions in external files, I am not a big fan (at all) of any use of 'src' attributes in executable content, since fetching the source may take a noticeable amount of time and create lag in the UI, even with good caching. I think it is preferable to insert external stuff into the SCXML before runtime, one way or another. Or load them asynchronously and use them once you get an event saying they are ready to use. David
Received on Tuesday, 28 January 2014 10:18:02 UTC