On 4/29/08, Ouyang, Landon - ES/RDR -Gil <[EMAIL PROTECTED]> wrote: > Ingmar, > > Thanks for the response. Our state machine maps states to specific > activities. It does not use a listener or a timer but rather a custom > class that utilizes an event stack for the firing of events within the > state routines. > > Your solution based on conditional transitions sounds like a reasonable > one. Given this information there are a couple more questions I have: > > 1) Is there a way to specify Java routines in the XML file to be > executed with the <onentry> tag? Possibly with <invoke>? We can then do > away with invoking state routine/handlers that are implemented in our > class (similar to AbstractStateMachine). > <snip/>
Possible with either (<invoke> for long running semantics, custom actions in <onentry> etc. for shorter routines). Specifically to your <onentry> question, see: http://commons.apache.org/scxml/guide/custom-actions.html For custom actions, map Java exceptions to logical outcomes (events) rather than throwing them. > 2) If the answer to question 1 is true, can we fire events within these > Java routines to determine the transitions within these states? If true, > we can forego your "cond" solution and instead use the Java routines to > determine the paths our state machine takes. > <snap/> There are two categories of events, external and internal / derived. For custom actions, you can trigger derived events (add any events to the derviedEvents collection in Action#execute(...) ). If you must fire external events, then the semantics of <invoke> are more suitable. Based on what I've read in this thread so far, I think a custom action will do (and has a considerably simpler execution model). -Rahul > Thanks! > > > Landon Ouyang > Member Technical Staff > ITT Electronics Systems, Radar Systems - Gilfillan > 7821 Orion Ave, > Van Nuys, CA 91406 > (818) 901-2982 > > > > -----Original Message----- > From: Ingmar Kliche [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 29, 2008 1:16 PM > To: Commons Users List > Subject: Re: [SCXML] XML engine decoupled from code > > Landon, > > I'm not sure if your CheckRotation is really a state. To me it sounds > more > like a guard condition (i.e. a condition) to decide which state to enter > (e.g. the state machine is in state A and some event arrives - which one > ? - > then check the guard condition and decide to go to B or C). Could you > elaborate a little on your state machine. What is the event which > is triggered? What drives your state machine? Is it a timer which > triggers > the engine on a regular basis? Or is it an external process that sends > events, or is it some user input, ...? > > The information which you need to check (i.e. bRotating) seems to be > available in the container application (the one that embedds the SCXML > engine). Isn't it possible to pass this information (bRotating) along > with > the event (i.e. as payload of the event) into the engine (something like > triggerEvent("???", bRotation))? In this case you could access bRotation > within the SCXML code: > > <state id="A"> > <transition event="???" cond="_eventdata.bRotation == true" > target="B"/> > <transition event="???" cond="_eventdata.bRotation == false" > target="C"/> > </state> > > Or could you use a CustomAction to access bRotation? > > There is certainly a solution for your problem, but it would help (at > least > me) if you could describe a little more (if possible). > > Best, > Ingmar. > 2008/4/29 Ouyang, Landon - ES/RDR -Gil <[EMAIL PROTECTED]>: > > > Hi, > > > > A conceptual issue has arisen after creating a working application > that > > uses the Commons SCXML engine. > > > > Based on what we want out of the engine, it is essentially important > > that the code implementation (Java) is decoupled/independent of the > > underlying engine (XML file). > > > > To illustrate the problems I encountered, here is an example: there is > a > > state called CheckRotation that can detect whether there is or isn't a > > rotation. We need the ability for a developer to be able to place this > > state anywhere in the state machine (possibly multiple times) and > direct > > the state machine based on one of the two outcomes without having to > > write any Java code; he should only have to edit the XML file. For > > example, one path could be A -> CheckRotation -> C or D and another > > could be E -> CheckRotation -> F or G. > > > > We can modify the Java code so the CheckRotation method could fire > > different events to direct the path. > > > > if(PrevState == A) > > { > > if(bRotating) > > fireEvent(EVENT_C); > > else > > fireEvent(EVENT_D); > > } > > else if(PrevState == E) > > { > > if(bRotating) > > fireEvent(EVENT_F); > > else > > fireEvent(EVENT_G); > > } > > > > But this solution adds complexity and defeats the whole purpose of > using > > the engine in the first place! The CheckRotation state would need > > multiple conditional transitions defined (instead of two) in the XML > > file and the Java code would be interlinked with the XML engine! Is > > there a more proper solution to this issue? > > > > -- > > Landon Ouyang > > Member Technical Staff > > ITT Electronics Systems, Radar Systems - Gilfillan > > 7821 Orion Ave, > > Van Nuys, CA 91406 > > (818) 901-2982 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
