- From: Nestor Urquiza <nestoru@yahoo.com>
- Date: Mon, 8 Jan 2007 06:11:17 -0800 (PST)
- To: www-voice@w3.org
Sounds great, Do you think the proposed <invoke> mechanism could change in future drafts? I am asking because current implementations like commons-scxml could potentially implement the full invoke mechanism including <finalize>. In regards to the returning data from <invoke> seems like the only way to get the result would be through <finalize> right? I am wondering how a sample use case like the below should look when using <invoke>: Build an external to invoke SCXML piece that returns the name of the pet knowing that: if animal type="dog" then name="Fido" if animal type="cat" then name="Kitty" if animal type="bird" then name="Tweety" How the above SCXML piece of code should look like if it must done using SCXML? >From the main SCXML we should be able to <invoke> several time within even different states the above bits passing param animal-type and getting back animal-name. How the <invoke> node should look like to pass the param when invoking? How the finalize node should look like to get the name back in the context variable animalName? <var name="animalName" expr="''"/> <finalize> <!-- what comes here? --> <assign name="animalName" expr="what.comes.here.?"/> </finalize> Many thanks, -Nestor > > > > --- "Barnett, James" <James.Barnett@aspect.com> > wrote: > > > Nestor, > > We have two reuse mechanisms in mind. First > off, > > <invoke> is > > definitely intended to be used so that one SCXML > > script can invoke > > another. Note that in this case, the two scripts > do > > not share any > > context (but parameters can be passed in and out). > > > Secondly, there is > > an include mechanism that will be expanded in the > > next draft that allows > > one state to include part or all of another script > > as if by copy, so > > that the copied material does share context with > the > > copying context. > > > > We hope that these two mechanisms will cover most > of > > the common reuse > > cases. > > > > - Jim > > > > -----Original Message----- > > From: www-voice-request@w3.org > > [mailto:www-voice-request@w3.org] On > > Behalf Of Nestor Urquiza > > Sent: Friday, January 05, 2007 4:05 PM > > To: www-voice@w3.org > > Subject: [SCXML] Reusing code through > > functions/templates > > > > > > Hello guys, > > > > I have been discussing about possibilities to > reuse > > code within SCXML and I wanted to know about the > > plans > > to offer those possibilities within the SCXML > > Specification [1]. > > > > Basically wherever executable content exists there > > is > > a clear need to reuse code and to apply DRY some > way > > of grouping code in functions/routines/templates > is > > needed. > > > > Currently I see the following possibilities and I > > would like to know about any others and of course > if > > there is already a preference among them. > > > > 1. <invoke> > > 2. <script> > > 3. Just as a proposal, I think an XSLT templating > > alike mechanism (just in terms of the syntax) > could > > be > > used to be able to call passing parameters a given > > template that in turns could return some result. > > > > Thanks, > > > > -Nestor > > > > [1] > > > http://marc.theaimsgroup.com/?t=116241382900003&r=1&w=2 > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > http://mail.yahoo.com > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Received on Monday, 8 January 2007 14:18:04 UTC