Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 36104 invoked from network); 8 Jan 2009 20:03:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jan 2009 20:03:34 -0000 Received: (qmail 45745 invoked by uid 500); 8 Jan 2009 20:03:29 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 45693 invoked by uid 500); 8 Jan 2009 20:03:29 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 45682 invoked by uid 99); 8 Jan 2009 20:03:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jan 2009 12:03:29 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of roger.hoover@gmail.com designates 209.85.200.170 as permitted sender) Received: from [209.85.200.170] (HELO wf-out-1314.google.com) (209.85.200.170) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jan 2009 20:03:21 +0000 Received: by wf-out-1314.google.com with SMTP id 28so9256517wfa.27 for ; Thu, 08 Jan 2009 12:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=f9SXGYTjEY7f8YSSA6vCmT+C0X6Y0f0fMEhTIpNjmBA=; b=hDrO4jQKPt3apukj6ENsUG1EMR6ujeGs53nwVQbZCF3KgKbuNZhr5Ih/N5ey/scnJv 2YK+A+E+e5tI9E28o2mlPjvh6O8wJTAvXJpttZVyh49WtklgJSuwheafdxoJzWcwQ2go gOp8/u2xwWHm/aufPRXj+iYNkog0++asTaP3M= 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:references; b=Ncof6bpNnq3zugYM2HCZS7f6i828fNFFSELNJcCqJX7ROiqR8PGVACzXmCT8hR2Chh wMNvi2kvZhjy6xVpE/FH8BOITVf2JxwpV/mBoONHC03mBfvMoJZErLBTcw49JRZ+WmxQ WWFEoOJu3pkLiDH9IeYFaaVcDIiAqxdMdA8yA= Received: by 10.142.226.10 with SMTP id y10mr10323535wfg.3.1231444978676; Thu, 08 Jan 2009 12:02:58 -0800 (PST) Received: by 10.143.167.1 with HTTP; Thu, 8 Jan 2009 12:02:58 -0800 (PST) Message-ID: <44cb1ba30901081202o4f7471f6oc7f7f44e11a32825@mail.gmail.com> Date: Thu, 8 Jan 2009 12:02:58 -0800 From: "Roger Hoover" To: "Commons Users List" Subject: Re: SCXML Templating In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_204554_22283919.1231444978664" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_204554_22283919.1231444978664 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Rahul, Please enlighten me if I'm missing something. It seems like the only reason that state names must be globally unique is that they need to be referenced by name in transitions. Why not reference them by something similar to XPath? In the example you gave earlier, the states could be uniquely identified by expressions such as "s1/foo, s1/bar, and s2/foo, s2/bar? In this way, the names would need to be unique only in their scope but not unique globally. I think it would make modularizing SCXML easier. What you think? Roger On Thu, Jan 8, 2009 at 11:22 AM, Rahul Akolkar wrote: > On Thu, Jan 8, 2009 at 2:04 PM, Joel Truher wrote: > > I'm curious about this topic, Rahul, since I encountered it as well. > > > > The solution you suggest seems to me to be external to SCXML, and it > > made me wonder if this sort of templating ought to be supported more > > natively, or if there's a design argument to exclude it? > > > > I searched for a way to avoid templating, since it does seem foreign > > to the state-chart idea (as well as other implementations of it, e.g. > > Boost.Statechart). I eventually succeeded, and I think my design is > > better for it. So maybe the exclusion of templates is a good design > > choice. Is that how you see it? > > > > > It has been a conscious design choice so far to say that ensuring the > uniqueness of IDs is the responsibility of the document author in all > cases. Some solutions were considered IIRC to automatically introduce > some sort of scoping or ID-munging to get around this issue of src'ing > in the same document multiple times, but none were found to be > satisfactory. Given that SCXML will very likely be used to design > systems that are distributed, reactive and heterogeneous it was > considered that its not a stretch to say use a dynamic URL here. The > advantage of the example approach outlined here is that it gives the > author complete control over how the IDs will be treated every time, > and these are therefore predictable at design-time. > > I'm not sure if you are saying you avoid templating or use some other > authoring pattern (if you'd like to share with all users, you can > create a wiki page if you want). The wiki is here [1] and open to all > (after a quick registration). > > -Rahul > > [1] http://wiki.apache.org/commons/SCXML/HomePage > > > > > > > Joel > > > > > > On Thu, Jan 8, 2009 at 10:41 AM, Rahul Akolkar > wrote: > >> On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil > >> wrote: > >>> Thanks for your response. > >>> > >>> I'm not familiar with using a JSP (assume are we talking Java Server > >>> Pages?) in the context of my application. Mine is a stand-alone Java > >>> GUI application using Swing with the state machine to respond to user > >>> actions and other system actions. Is there a way to use a dynamic > >>> resource without using JSP? If so, what would an example look like? > >>> > >> > >> > >> It doesn't have to be a JSP, it was used for illustration. All we're > >> saying is use a dynamic URL to tweak the IDs as needed. If everything > >> has to be local (no servlet container, web server or any type of > >> remote service access), then it may not be straightforward to create > >> such a dynamic URL (custom protocol handlers for the java.net.URL > >> architecture or other fancy footwork perhaps). > >> > >> -Rahul > >> > >> > >>> Thanks a bunch, > >>> Cheryl > >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org > For additional commands, e-mail: user-help@commons.apache.org > > ------=_Part_204554_22283919.1231444978664--