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: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [SCXML] XML engine decoupled from code
Date: Tue, 29 Apr 2008 15:06:45 -0700
Message-ID: 
 <BDDC2E39D59D4D48984BB961677A2F10434017@vnexch01.gilfillan.de.ittind.com>
In-Reply-To: <cc9610990804291315p1e202cfva50461282a3c4459@mail.gmail.com>
Thread-Topic: [SCXML] XML engine decoupled from code
Thread-Index: AciqNfN2mAxyqoSvSHCnECq1/5nnBwACVUpg
References: 
 <BDDC2E39D59D4D48984BB961677A2F104336D8@vnexch01.gilfillan.de.ittind.com>
 <ce1f2ea80804101821i7982df46ga266899c8a541774@mail.gmail.com>
 <BDDC2E39D59D4D48984BB961677A2F10433737@vnexch01.gilfillan.de.ittind.com>
 <BDDC2E39D59D4D48984BB961677A2F1043373F@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>
From: "Ouyang, Landon - ES/RDR -Gil" <Landon.Ouyang@itt.com>
To: Commons Users List <user@commons.apache.org>

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

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.

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=3D"A">
   <transition event=3D"???" cond=3D"_eventdata.bRotation =3D=3D true"
target=3D"B"/>
   <transition event=3D"???" cond=3D"_eventdata.bRotation =3D=3D false"
target=3D"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 =3D=3D A)
> {
>        if(bRotating)
>                fireEvent(EVENT_C);
>        else
>                fireEvent(EVENT_D);
> }
> else if(PrevState =3D=3D 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
>
> This e-mail and any files transmitted with it may be proprietary and
are
> intended solely for the use of the individual or entity to whom they
are
> addressed. If you have received this e-mail in error please notify the
> sender. Please note that any views or opinions presented in this
e-mail are
> solely those of the author and do not necessarily represent those of
ITT
> Corporation. The recipient should check this e-mail and any
attachments for
> the presence of viruses. ITT accepts no liability for any damage
caused by
> any virus transmitted by this e-mail.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

This e-mail and any files transmitted with it may be proprietary and are in=
tended solely for the use of the individual or entity to whom they are addr=
essed. If you have received this e-mail in error please notify the sender. =
Please note that any views or opinions presented in this e-mail are solely =
those of the author and do not necessarily represent those of ITT Corporati=
on. The recipient should check this e-mail and any attachments for the pres=
ence of viruses. ITT accepts no liability for any damage caused by any viru=
s transmitted by this e-mail.

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