Return-Path: 
 <commons-user-return-19509-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 45175 invoked from network); 6 Jul 2007 20:42:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Jul 2007 20:42:49 -0000
Received: (qmail 32039 invoked by uid 500); 6 Jul 2007 20:42:47 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 31729 invoked by uid 500); 6 Jul 2007 20:42:46 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 31714 invoked by uid 99); 6 Jul 2007 20:42:46 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2007 13:42:46 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of rahul.akolkar@gmail.com
 designates 64.233.166.179 as permitted sender)
Received: from [64.233.166.179] (HELO py-out-1112.google.com) (64.233.166.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2007 13:42:40 -0700
Received: by py-out-1112.google.com with SMTP id a25so667103pyi
        for <commons-user@jakarta.apache.org>;
 Fri, 06 Jul 2007 13:42:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nVzwjl0XzHVWdCGZfqSmwuqmeVC5PqBBqNybADGBl8xBodUzFex43GwQY4iz406mIdbeRhNZLgP4PE28INupTy167R5EPp+7p63vK7Rldrfu5YInYNqg/0IpaFEagy4JDmuATBIy5MsIj1NwccUFYbe/PH4wV1ubH3RGj5CPnaQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TN45kg785fEGF8GyVbDcUQceqJywykt0uca3mgpKPB9AcLvnmikJFMJQ3WFfD/v8jU/VaSYB0vwLC+vDxHVW4sJpUv8o+yLZ/hE92RiW0ua++jR+NKK5HUdaeexg4qb6KVF4dCUCbG4rj/DUfX2zFhoqzUFc1PLkBYT7HAs1y+s=
Received: by 10.65.72.7 with SMTP id z7mr1865130qbk.1183754540079;
        Fri, 06 Jul 2007 13:42:20 -0700 (PDT)
Received: by 10.65.186.3 with HTTP; Fri, 6 Jul 2007 13:42:20 -0700 (PDT)
Message-ID: <ce1f2ea80707061342u69c5f51as44b510ebd4138251@mail.gmail.com>
Date: Fri, 6 Jul 2007 16:42:20 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [SCXML] Automatic forward of external events to <invoke>'d
 components ?
In-Reply-To: <cc9610990707061043v5f4211f9ldaf63ad5a3baaea4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <cc9610990707061043v5f4211f9ldaf63ad5a3baaea4@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 7/6/07, Ingmar Kliche <ingmar.kliche@googlemail.com> wrote:
> Rahul,
>
> it seems to me that the current implementation automatically forwards
> (external) events to <invoke>'d child state machines (or other components):
>
> see: triggerEvents() of SCXMLExecuter.java
>
>    // Forward events (external only) to any existing invokes,
>    // and finalize processing
>    semantics.processInvokes(evts, errorReporter, scInstance);
> Do I understand this comment correctly? Is this intended? I actually do not
> understand the current SCXML WD in this way [1].
<snip/>

It is my interpretation of, quoted from your reference:

"Note that the <invoke> element may be used to invoke an external
SCXML interpreter to execute a different state machine. In this case,
the external state machine acts as a set of substates of the invoking
state. The behavior is thus similar to a complex state defined with
<state> child elements."

One would expect substates to receive all the same events.


> I would like to have
> control which events to forward to an invoked component at markup level,
> something like:
>
> <state id="invoker">
>  <invoke targettype="scxml" src="invoked-01.xml">
>   <param name="foo" expr="'foo'" />
>   <param name="bar" expr="'bar'" />
>
>   <finalize>
>    <log expr="'Finalizing ...'" />
>   </finalize>
>  </invoke>
>
>  <transition event="foo">
>   <send event="foo" target="invokedID" targettype="SCXML"
> namelist="_eventdata"/>
>  </transition>
>  <transition event="invoker.invoke.done" target="end" />
> </state>
> What do you think?
>
<snap/>

Makes sense, and should be possible. If you want to track this, please
open a ticket in JIRA [1]. I may not be able to get to it for a couple
of weeks. If you want to take a stab at it, you will have to modify
the execute() method in oacs.model.Send. Currently, the "invokedID" is
effectively the ID of the parent <state>, but that may need to be
revisited as well.

-Rahul

[1] http://jakarta.apache.org/commons/scxml/issue-tracking.html


> Regards,
> Ingmar
>
>
> [1] http://www.w3.org/TR/2007/WD-scxml-20070221/#Invoke
>

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