commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] Help with SCXML Send usage
Date Tue, 06 Dec 2005 21:27:32 GMT
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 if
> 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 for
> 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 outcome.

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