Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 74211 invoked from network); 24 Jul 2007 18:38:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jul 2007 18:38:51 -0000 Received: (qmail 13148 invoked by uid 500); 24 Jul 2007 18:38:47 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 13087 invoked by uid 500); 24 Jul 2007 18:38:46 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 13076 invoked by uid 99); 24 Jul 2007 18:38:46 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 11:38: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.181 as permitted sender) Received: from [64.233.166.181] (HELO py-out-1112.google.com) (64.233.166.181) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 11:38:44 -0700 Received: by py-out-1112.google.com with SMTP id a25so4145417pyi for ; Tue, 24 Jul 2007 11:38:23 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZJFnim3ObbW4BwYqJWQtu01rEQ6mx31sW5Nzov61BR3BvF/m38lr4CLIdS+JlOPj71AEcH1XIzyCtu3AZ1ejoE388G7GZAIx18uHH4o8izneACYEvHWqRwlspU0vEVh/dTZN19lszTM+Ka6hX1Y03n60m9fzOA2S+TsB1pS0tBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TM7MQpb8VtJulP3vgQQqNOZ0Pw/hE84LzLsE+qowd2ENF4cet24IJELA1DzHiwKtQKs+CsLfKU9FjtmO1OI0hfluBlYET8nVCaLuJzwAjpw5pyb1f53dGZ+di09sXQ6xW0QL+ja3sjqsPQpFSIaCxcVidTWo2oASYotAewb2/A8= Received: by 10.65.121.9 with SMTP id y9mr7006351qbm.1185302302962; Tue, 24 Jul 2007 11:38:22 -0700 (PDT) Received: by 10.65.186.12 with HTTP; Tue, 24 Jul 2007 11:38:22 -0700 (PDT) Message-ID: Date: Tue, 24 Jul 2007 14:38:22 -0400 From: "Rahul Akolkar" To: "Jakarta Commons Users List" Subject: Re: [SCXML] Querying if an event would cause a transition Cc: CGI@zurich.ibm.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References:

X-Virus-Checked: Checked by ClamAV on apache.org On 7/24/07, Christopher Giblin wrote: > Hi, > Update: In the meantime, I have implemented a TransitionDetector class > which implements SCXMLListener and is registered with SCXMLExecutor. > It is only slightly odd to program: > > transitionDetector.reset(); > fsmExecutor.triggerEvent(ev); > System.out.println("Transition : " + transitionDetector > .isTransitionOccurred()); > Indeed. On the plus side, that can work off of the latest release. > That gives me a tactical solution for the time being. If I find that a > query, as suggested in my original post, really is required, I will get > back. > I think in the longer term it will be possible to offer that feedback via the SCXMLExecutor#triggerEvent() method(s), which currently have a void return type (they could either return a boolean or the actual list of transitions followed -- which could be empty). This will require a major release (v1.0) if implemented, due to the change in method signature. If you want to make sure this stays on the radar, please file a ticket in JIRA [1]. -Rahul [1] http://jakarta.apache.org/commons/scxml/issue-tracking.html > Thanks, chris > > > Christopher Giblin/Zurich/IBM wrote on 07/24/2007 12:00:36 PM: > > > Hi, > > > > Sorry for the delayed response. My remarks below. > > > > > Please prefix the email subject with [SCXML], since this mailing list > > > is shared across all Commons components. I've added the prefix here. > > > > Thanks - I will be sure to in the future. > > > > > On 6/27/07, Christopher Giblin wrote: > > >> > > >> Hi, > > >> I am new to Commons SCXML. > > >> Is it possible to determine whether an event would result in a > transition, > > >> without that transition occuring? Including evaluation of transition > > >> conditions? > > > > > > > > > While the idea is interesting, we do not have such an "introspection > mode". > > > > > > It wouldn't take too much effort to implement it, but: > > > > > a) Would probably increase the code smell factor a tad (if in > > > introspection mode, then follow transition else just report back etc.) > > > > > b) Would require some API additions that might warrant a major > release. > > > > > If you don't mind sharing in this public forum, why do you need such > > > introspection? The SCXML specification doesn't talk about this. > > > Understanding that interaction pattern may or may not help better > > > answer the question, we will have to see :-) > > > > I am using SCXML to describe allowable states for an application. > > Every event should result in a state transition. If no transition, > > then I need to raise an error. Adding error states to the state > > machine complicates it significantly. By comparison, simply > > expressing all allowable transitions is more elegant. This requires > > that the engine can be queried with an event to determine if it > > would result in a transition. By default, SCXML ignores non- > > applicable events, remaining in the current state. Remaining in the > > same state is ok, but I need to know if an event transition occurred > > or not, as said. One approach would be to register as a listener to > > determine if a transition occurred. This results in an awkward > > programming style, however, further compounded by my app having > > perhaps hundreds of state machines. A program would be easier to > > read if one could ask the engine if the event leads to a transition. > > > > I also considered clone the state machine, listening and then > > triggering the event. Too much overhead, though. My code must also > > be efficient. > > > > Or do you see a better way of dealing with this? > > > > Thanks, chris > > > > > > > > > -Rahul > > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org