commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fasih" <fasihullah.ask...@baypackets.com>
Subject Re: [SCXML] Parallel States
Date Mon, 08 May 2006 21:00:02 GMT
Thanx
I dont think that I really got your example!
What will src="http://foo.bar/baz.scxml?param=1" do. More precisely, who is 
"producing" the SCXML template? Reading your mail I thougth you are 
suggesting something like
src=http://foo.bar/baz.jsp?param=1 which would produce an SCXML! In any 
case, how does the param=1 help. Are you saying that I just add param=1 
param=2 etc to "fool" the scxml engine to think that they are different 
external srcs?
 By the way, what purpose does param=1 serve, other than being "intervowen" 
into ids? Does this mangling change the way I have done something? As in, if 
an event is thrown from baz.scxml will it be mangled too?

As an aside [;)] I did realize after some more snooping around that the 
problem is due to the same external ref that I am using, had it not been for 
the parallel, the SCXML would not have gone into an "illegal config"

+Fasih
----- Original Message ----- 
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Sent: Monday, May 08, 2006 3:44 PM
Subject: Re: [SCXML] Parallel States


On 5/7/06, Fasih <fasihullah.askiri@baypackets.com> wrote:
> Hello ppl
> I am trying to create a state with external source, but stargely enough, 
> the state machine enters the state "automatically". my xml:
> <scxml
>  xmlns="http://www.w3.org/2005/07/SCXML"
>  initialstate="setup-call">
>    <state id="setup-call">
>        <parallel id="ivr-interaction">
>          <state id="orig-leg"/>
>          <state id="ivr-leg">
>            <initial>
>              <transition target="external-ivr"/>
>            </initial>
>            <state id="external-ivr" src="external-hello.scxml"/>
>          </state>
>        </parallel>
>    </state>
>    <state id="hungup" src="external-hello.scxml"/>
> </scxml>
>
> external-hello.scxml
> <scxml
>  xmlns="http://www.w3.org/2005/07/SCXML"
>  version="1.0"
>  initialstate="wait-for-ivr-request">
>  <state id="wait-for-ivr-request"/>
> </scxml>
>
>
> Results in:
> [main] WARN org.apache.commons.scxml.env.SimpleErrorReporter - 
> ILLEGAL_CONFIG (Not all AND states active for parallel ivr-interaction): 
> /setup-call/ivr-interaction : [/setup-call/ivr-interaction/orig-leg]
> [main] WARN org.apache.commons.scxml.env.SimpleErrorReporter - 
> ILLEGAL_CONFIG (Multiple top-level OR states active!): <SCXML> : 
> [/setup-call, /hungup]
>
> Any clues as to what is wrong in this????
>
<snip/>

Including external-hello.scxml twice in the parent document gave us
two states with ID "wait-for-ivr-request". Since the transition target
for the <initial> in "ivr-leg" is really meant to be an IDREF, that
throws the engine off.

What you're trying to do is a perfectly valid usecase. This is
sometimes referred to as "state templating", and the preferred way to
achieve this is to therefore use some templating technology (be it a
JSP that produces SCXML, or a Velocity template, or something else).
For example:

<scxml ... >

  <state id="foo1" src="http://foo.bar/baz.scxml?param=1">
    <!-- possibly something here -->
  </state>

  <state id="foo2" src="http://foo.bar/baz.scxml?param=2">
    <!-- possibly something (else) here -->
  </state>

</scxml>

And the param gets woven into the IDs and other relevant bits of the
generated SCXML snippet (to eliminate duplicate IDs, for one).

As an aside, this is not related to parallelism, other than <parallel>
just happens to be present in this particular example.

-Rahul



> Any help greatly appreciated
>
> +Fasih
>
>

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




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


Mime
View raw message