Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of rahul.akolkar@gmail.com
 designates 209.85.128.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ZEdckSS37H8W42cZ14AtURA7YAwmDBrMETR/pAT9riHmiiTRCvqFZMvJ67q6OEBV3JyWyDRVsiv+bvjBe688nnpftFMgf94+pYcNEDqBp7JETwTNwIyDIIBbMUBSMH3MpK2PEqEvwFN/16XyBMx1j8exfXEg8VQPdbpkdTS/njg=
Message-ID: <ce1f2ea80805011239k61c1481cx9f07bffc4bb7dc6@mail.gmail.com>
Date: Thu, 1 May 2008 15:39:36 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Commons Users List" <user@commons.apache.org>
Subject: Re: [SCXML] XML engine decoupled from code
In-Reply-To: 
 <BDDC2E39D59D4D48984BB961677A2F10434119@vnexch01.gilfillan.de.ittind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <BDDC2E39D59D4D48984BB961677A2F104336D8@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804111417j6bd29191xcb60d34b1c9378cf@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F1043375C@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804111855q2fddc8acxb99f1a3ea4a3fb84@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F104337A2@vnexch01.gilfillan.de.ittind.com>
	 <BDDC2E39D59D4D48984BB961677A2F10433FB6@vnexch01.gilfillan.de.ittind.com>
	 <cc9610990804291315p1e202cfva50461282a3c4459@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F10434017@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804301114h6d1646cy603ed697031f6072@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F10434119@vnexch01.gilfillan.de.ittind.com>

On 4/30/08, Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com> 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:rahul.akolkar@gmail.com]
>  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 <Landon.Ouyang@itt.com> 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:ingmar.kliche@googlemail.com]
>  >  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 <Landon.Ouyang@itt.com>:
>  >
>  >  > 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org