Re: Suggestions for onentry/onexit tags

Hello,


 >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…

It would be a single <onentry> with multiple tags with code blocks inside.
 From here it would also easily possible to extend functionality. For 
example attributes:
<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.

 >
 >> 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.

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.

 >
 >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.

I am not a big fan neither, unless it helps.
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.

 >
 >                       David


Thanks,

Andreas

Received on Tuesday, 28 January 2014 13:16:55 UTC