Return-Path: 
 <commons-user-return-18343-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 23674 invoked from network); 5 Jan 2007 20:29:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 5 Jan 2007 20:29:06 -0000
Received: (qmail 87985 invoked by uid 500); 5 Jan 2007 20:29:08 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 87941 invoked by uid 500); 5 Jan 2007 20:29:07 -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 87930 invoked by uid 99); 5 Jan 2007 20:29:07 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jan 2007 12:29:07 -0800
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.184.233 as permitted sender)
Received: from [64.233.184.233] (HELO wr-out-0506.google.com) (64.233.184.233)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jan 2007 12:28:58 -0800
Received: by wr-out-0506.google.com with SMTP id i20so2738811wra
        for <commons-user@jakarta.apache.org>;
 Fri, 05 Jan 2007 12:28:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WwgIkDlbosoGA111UM7fX9rda6Ru9Wkun5fVNpHlPSFUjfSg3c2V9Z9tcG4um7nLqfQagDYOk6h6gDAopJZGiYYz329CP8685WD7/qX7phgH4mGHC2Krgkpa5ux/cTJcGastRbLBalB9knE2ayDyiiAtAculs/YsXqEWnRkanJ4=
Received: by 10.78.17.4 with SMTP id 4mr4686971huq.1168028917792;
        Fri, 05 Jan 2007 12:28:37 -0800 (PST)
Received: by 10.78.165.12 with HTTP; Fri, 5 Jan 2007 12:28:37 -0800 (PST)
Message-ID: <ce1f2ea80701051228x51884577u49d11ee82fff40d4@mail.gmail.com>
Date: Fri, 5 Jan 2007 15:28:37 -0500
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [scxml] including chunks of scxml code.
In-Reply-To: <215983.35195.qm@web50904.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ce1f2ea80701051030s7efbf002x894e74048ac9c3e0@mail.gmail.com>
	 <215983.35195.qm@web50904.mail.yahoo.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 1/5/07, Nestor Urquiza <nestoru@yahoo.com> wrote:
> Hi Rahul,
>
> While java can be used of course and I use it for a
> lot of helper methods like the one you propose for the
> given example, it breaks the needed separation of
> concerns for my case.
>
<snip-example/>
>
> While of course the example is simple to illustrate
> the need the bottom line is that I want to use (and I
> am using) commons-scxml as a Controller and so
> business rules (very complex ones) can be added
> without recompilation or java releases, accesible to
> operations guys that are very close to business people
> and far away from software developers.
>
<snap/>

There was a suggestion about XML entities; that is one possibility to
avoid recompilation, and works for executable content (where IDs are
not used).


> So, from your reply I understand commons-scxml does
> not implement <invoke> still. We have to wait for an
> agreement from W3C for invoke final implementation
> right?
>
<snip/>

<invoke> is in place, its just not advertised very much since we know
it may change. For example, you can register an invoker class for a
given targettype on the executor (see SCXMLExecutor Javadoc and follow
along from the registerInvokerClass() method).


> Just thinking aloud, I would expect SCXML to have
> features like XSLT templating which is nothing but the
> ability to reuse code thru functions. What you think?
>
<snap/>

All ideas are welcome. Some may be suitable for the spec (and won't be
handled here, unlike those for the impl).

-Rahul


> Thanks a bunch,
>
> -Nestor
>
>
<snip/>

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