You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Daniel Schwager <Da...@dtnet.de> on 2008/07/18 12:26:54 UTC

[SCXML] featurerequest for new listener SCXMLPostExecutionListener

Hi Rahul,

I would like to trigger automat FSM2, if an event1 will fired on the
FSM1.

This could be done easily be done using a normal SCXMLListener, 
if a state changed in FSM1. 

But the SCXMLListener will not be called from SCXML, if 
nothing change inside of FSM1 (means, event1 will not map 
to any rule defined in the XML-file).

So, I have no change to trigger FSM2 via Listener/Action/Invoke 
in this szenario (or did I miss something ?)

A Solution could be to implement a new Listener interface 

    Public interface SCXMLPostExecutionListener extends SCXMLListener {
	// value true, if at least one fsm.trigger() called
      Void onTrigger(Boolean value)	
            
	// value true, if fsm.go() called
	Void onGo(Boolean value)		
		
	// value true, if at least one onExit/Entry/Transistion occurred
	Void onExit/Entry/Transition(Boolean value)  	
    }

which, if a SCXMLPostExecutionListener has registered, will be called
AFTER (post execution) the execution of FSM has finised.

Another (but not recommended) solution is to integrate a parallel 
watchdog-state in the FSM1 which will change every time fired by any
event. 

I do not like this solution (but it works ;-), because I want not 
solve a technical problem (missing of something like
SCXMLPostExecutionListener) 
by changing the functional automat-description like this

  <parallel>
    <state id="functional_business_logic">
	...
    <state>
    
    <state id="watchdog_global">
	<initial>
		<transition target="watchdog" />
	</initial>
	<state id="watchdog">
		<transition event="*" target="watchdog" />
	</state>
    </state>
  </parallel>


Or is there another way to track down my requirement described above ?


Regards
Danny

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: [SCXML] featurerequest for new listener SCXMLPostExecutionListener

Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jul 18, 2008 at 6:26 AM, Daniel Schwager
<Da...@dtnet.de> wrote:
> Hi Rahul,
>
> I would like to trigger automat FSM2, if an event1 will fired on the
> FSM1.
>
> This could be done easily be done using a normal SCXMLListener,
> if a state changed in FSM1.
>
> But the SCXMLListener will not be called from SCXML, if
> nothing change inside of FSM1 (means, event1 will not map
> to any rule defined in the XML-file).
>
> So, I have no change to trigger FSM2 via Listener/Action/Invoke
> in this szenario (or did I miss something ?)
>
<snip/>

In v0.8, using <invoke> triggers all events from the parent state
machine on the child state machine (so FSM1 would be the parent
<invoke>'ing FSM2). However, note that this behavior is currently
under discussion at the Working Group level and is subject to change.
As the Commons SCXML home page notes (in the "Releases" section),
<invoke> is not completely fleshed out yet and the behavior may change
in subsequent releases.


> A Solution could be to implement a new Listener interface
>
>    Public interface SCXMLPostExecutionListener extends SCXMLListener {
>        // value true, if at least one fsm.trigger() called
>      Void onTrigger(Boolean value)
>
>        // value true, if fsm.go() called
>        Void onGo(Boolean value)
>
>        // value true, if at least one onExit/Entry/Transistion occurred
>        Void onExit/Entry/Transition(Boolean value)
>    }
>
> which, if a SCXMLPostExecutionListener has registered, will be called
> AFTER (post execution) the execution of FSM has finised.
>
<snap/>

The reason why we set up listeners for exit / transition / entry is
that these are by-products of processing events. The user isn't
actively making each of those individual things to happen. The
suggestions above (such as onTrigger(), onGo() etc.) may be handled by
a "manager" component that is user-provided (we have always advocated
having components that manage the external event queues and overall
lifecycle -- such as go(), trigger(), reset() etc. -- it may be
possible for such a component to turn around and do the "post
execution" bits you are talking about above.)


> Another (but not recommended) solution is to integrate a parallel
> watchdog-state in the FSM1 which will change every time fired by any
> event.
>
> I do not like this solution (but it works ;-), because I want not
> solve a technical problem (missing of something like
> SCXMLPostExecutionListener)
> by changing the functional automat-description like this
>
<snip/>

Yes, I see why you don't like it. Incidently, there is no reason to
have the "watchdog_global" state be composite (it doesn't need to have
an <initial> and a <state>, it just needs the one self transition that
the "watchdog" state has).

-Rahul


>  <parallel>
>    <state id="functional_business_logic">
>        ...
>    <state>
>
>    <state id="watchdog_global">
>        <initial>
>                <transition target="watchdog" />
>        </initial>
>        <state id="watchdog">
>                <transition event="*" target="watchdog" />
>        </state>
>    </state>
>  </parallel>
>
>
> Or is there another way to track down my requirement described above ?
>
>
> Regards
> Danny
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org