commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr -" <>
Subject RE: [SCXML] Help with SCXML Send usage
Date Wed, 07 Dec 2005 00:43:31 GMT
Hi Rahul,

I appreciate the direction and if we get the <send> contents </send>
code working, I'll send it to you to choose what you want to
incorporate, or tell me what we did wrong more likely.  :-).  I'm hoping
to build a useful tool for a specific purpose but aim to design it
flexible enough that we can extend in the future as a multimodal

I would like to keep in touch and contribute where I can.  If you
haven't seen yet, visit this link:

I think the big boys are waiting for the maturity of this to spec out
the browsers of the future (built-in to clients like GPS devices,
phones, pdas, etc.).  You've done a great job and I do hope to build
upon that and increase the audience.

I also have another developer working locally helping me publish and
subscribe to a web service, exposing some useful public data.  I will
publish this service and provide all source code for free with tutorials
to teach others how to write, publish and subscribe to web services.  I
can share that with you when ready too.



-----Original Message-----
From: Rahul Akolkar [] 
Sent: Tuesday, December 06, 2005 2:28 PM
To: Jakarta Commons Users List;
Subject: Re: [SCXML] Help with SCXML Send usage

On 12/6/05, Mike Sparr - <> wrote:
> Rahul,
> I appreciate your response.  Yes, I did look at RDC and it does not 
> meet my needs.  Your musicstore app required you to write two separate

> pages (one for GUI, one for voice) although yes, you did get to reuse 
> the dialog and leverage your tags.
> What I want is to have a single input (String) and output (XSL 
> formatted
> String) and a single file that defines our conversation.  Essentially
> I deploy a client plug-in, it will transform whatever input received
> into my single input and pass to my app, along with client type and
> handle.  My app will process the input based on conversation rules
> defined in SCXML and ultimately return a formatted string using XSL
> that particular client.
> I don't want to write JSPs for each, but rather have a single 
> input/output defined and write my app flow and logic using SCXML/VXML.

Sure, my intent wasn't to thrust another technology (JSP) or another
framework (RDC) upon you, but to indicate what I think is a path of
least resistance for *scalable* applications using building blocks
available at Apache right this moment. And that is probably important
given that you're paying by the hour. Using the RDC template [1], things
should be fairly straightforward. Having said that, lets move the
discussion to where you (and some of us as well) would like to be i.e. a
compound document that supports VoiceXML snippets in the body of the
SCXML <send>.

> The SCXML spec:
> This shows that you can declare a namespace and embed tags within the 
> Send element.  Given vxml is structured for dialog, I hope to use it 
> in defining my "screens" using <form> and <menu> and letting XSL 
> format it for that particular client.
> It's pretty simple, just need help getting the contents of Send.  I am

> paying a developer to help me so every hour is costing me... Ouch. Any

> help you can provide, even a quick/dirty example of adding some rules 
> would be a great help.
> If you could tell me what to add, I can have my "helper" add it for 
> our purpose.  My guess is either modify line 264:
> "/send"
>  to
> "/send/form/block/prompt"
> - I'm unfamiliar with how this works?
> I assume then some modification to after line 579 in 

Mike, check out the SCXML source Xref [2] which allows to point / link
to line numbers in code. Line 264 for SCXMLDigester [3] seems to lead
somewhere other than what you mention, so does like 579. In any case,
I'd recommend that anyone working with this code read up on Commons
Digester, you'll find much information on the digester website [4] and
wiki [5]. Specifically, I'd look up the NodeCreateRule I pointed to
yesterday to grab all content under the <send> and on getting the onSend
callback on the EventDispatcher, marshall the VoiceXML bits to the voice
browser. On the way back, you'll need to get the value specified by the
user, and make it available in the context of execution for the
SCXMLExecutor, and the easiest way to do that is to do a
Context#set(String,Object) on the RootContext, which may be accessed
using scxmlExecutor.getStateMachine().getRootContext(). The user's input
is now available to be part of the decision making for the next logical

The RDC framework does something similar under the hood to enable
plugging SCXML controllers.

>    /**
>      * Add Digester rules for all actions (&quot;executable&quot; 
> elements).
>      *
>      * @param xp The Digester style XPath expression of the parent
>      *           XML element
>      * @param scxmlRules The rule set to be used for digestion
>      */
>     private static void addActionRules(final String xp,
>             final ExtendedBaseRules scxmlRules) {
>         addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
>         addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
>         addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
>         addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);

The digester processing in the line above will need to change to grab
arbitrary external namespace children. I still need to look at digester
closely in the realm of multiple namespaces (probably will this
weekend), but a NodeCreateRule seems like the best bet here (or search
the commons-user / dev archives for similar questions).

>         addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
>         addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
>     }
> Any help or just some sample code how to modify would be a great help!

Once you get this bit going, that'd be quite a nice demonstration of
SCXML. If you're so inclined, I'd suggest thinking about contributing
back to the Commons SCXML community so the enhancements you've made are
available to the rest of us.



> Thanks,
> Mike

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message