On 4/30/08, Ouyang, Landon - ES/RDR -Gil <[EMAIL PROTECTED]> wrote:
> Rahul,
>
> Thanks once again for the quick response.
>
> Before reading your e-mail I had already decided to go with the <invoke>
> route for developing our implementation. I made our state machine class
> an invoker class and registered it with the SCXML executor. The invoke()
> method would trim the string passed in as the source parameter and
> invoke the method similar to the AbstractStateMachine class. I am now
> able to add statements in the XML that utilize the <invoke> tag to
> invoke Java methods defined inside the state machine class.
>
> I ran into a problem which leads me to believe I may have chosen the
> wrong route: I cannot access the initiated values of the class!
<snip/>
As in static fields? Should be possible.
> For
> example, the state machine needed access to the GUI to change various
> widgets. I had a member assigned to the JFrame to accomplish this but
> this member is now null in the invoked method even though I correctly
> initialized it earlier! This never happened before until I transformed
> the state machine class to an invoker class. Is the Invoker object a
> separate instance of the original state machine object?
>
<snap/>
Each <invoke> gets a new instance of the Invoker class. If you need to
"initialize" the instance with handles to other bits (such as a
JFrame, in this example), those need to be in the state machine's
Context and passed in as <param>s.
IOW, an example in code:
0) Say myJFrame is the frame
executor.getRootContext().set("frame", myJFrame);
1) Markup fragment
<invoke ...>
<param name="frame" expr="frame"/>
...
</invoke>
2) In invoker#invoke(String src, Map params) .... params.get("frame")
gets you the frame.
Finally, as mentioned on the Commons SCXML homepage (and the spec in
progress), <invoke> is evolving.
-Rahul
>
> --
>
> Landon Ouyang
> Member Technical Staff
> ITT Electronics Systems, Radar Systems - Gilfillan
> 7821 Orion Ave,
> Van Nuys, CA 91406
> (818) 901-2982
>
> -----Original Message-----
>
> From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 30, 2008 11:15 AM
> To: Commons Users List
> Subject: Re: [SCXML] XML engine decoupled from code
>
> 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]
