commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr - www.goomzee.com" <m...@goomzee.com>
Subject [SCXML] Help with SCXML Send usage
Date Tue, 06 Dec 2005 08:40:33 GMT
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.  

The SCXML spec:
http://www.w3.org/TR/2005/WD-scxml-20050705/#N104B9

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 SCXMLDigester.java:

    /** 
      * 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); 
         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!

Thanks,


Mike




-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: Tuesday, December 06, 2005 12:02 AM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Help with SCXML Send usage


Hi Mike -

This is an interesting question, but before I attempt to answer -- I've
modified the email subject with a [SCXML] prefix, please try to add the
prefix when you start a thread, since some of us have email filters set
up.

On 12/5/05, Mike Sparr - www.goomzee.com <mike@goomzee.com> wrote:
> We are trying to parse/use the content between <send> </send> tags and

> everything we try using the SCXML digester and Send methods retrieves 
> null.  We have successfully captured the <var> values, but nothing 
> within <send> tags.  Can you please provide information on how to 
> retrieve this content using the code?  Our SCXML test document is 
> below:
>
> <?xml version="1.0"?>
> <scxml xmlns="http://www.w3.org/2005/07/SCXML"
>       version="1.0"
>       initialstate="logoff">
>
>  <state id="logoff">
>    <onentry>
>      <var name="drink" expr="water" />
>        <var name="eat" expr="flies" />
>        <send target="http://localhost:8080/VXMLInterpreter"
> targettype="v3" xmlns:v3="http://www.w3.org/2005/07/vxml3"
> namelist="drink eat" event="" hints="" sendid="" delay="0">
>            <v3:form id="Welcome">
>              <v3:block><v3:prompt>Please enter your 
> name.</v3:prompt></v3:block>
>            </v3:form>
>          </send>
>        <log expr="'@@@@@@executed send@@@@@@@@'"/>
>
>      <cancel sendId="send12345"/>
>    </onentry>
>
>    <transition event="go_login">
>      <target next="login"/>
>    </transition>
>  </state>
>
>  <state id="login">
>      <transition event="go_logoff">
>        <target next="logoff"/>
>     </transition>
>  </state>
>
> </scxml>
>
>
> Please help in allowing us to get the SCXML code to work.  We've tried
> getExternalNodes() within Send and looked into the Rules for digester 
> and do not know how to retrieve the <send>text</send> body elements.
>
<snip/>

Sorry, that digester rule is not in the current SCXMLDigester [1]. Let
me take this up as a TODO for myself, I'll try to get to this during the
upcoming weekend. I'll attempt to use NodeCreateRule [2] to prepare the
external nodes, but since we also need to process the known bits of the
SCXML <send> element, there'll be more than one digester rule involved.

This will allow the SCXML engine to react to external namespaces, as
long as the EventDispatcher [3] can locate a suitable namespace handler.
I believe SCXML has much promise when it comes to playing in Compound
Document Frameworks.

Having said that, a different approach is equally powerful, and
available immediately. I have written applications which do exactly what
you're alluding to above i.e. thinking of conversations as states and
transitions where each state has a corresponding activity which might be
a dialog of arbitrary complexity (one or more prompts and replies,
client side interaction or even multiple round trips to the server).

IIRC you've looked at the RDC framework [4], and it provides a SCXML
dialog management strategy for the group container [5]. A very simple,
fictitious use case example is here [6] for which the SCXML controller
is here [7]. Wrapping each activity in a RDC gives us:

a) A separation between the controller and the view
b) The interaction that needs to happen when you're in a particular
state can be fairly involved including any number of client server round
trips
c) You can make decisions about the transition you'd want to follow
based on prior interaction(s)

The separation in (a) is especially useful if you're authoring
multi-channel applications (voice, GUI, small device) since it
encourages reuse across different view layer markup. We have a multi
channel example [8] in the RDC distro which uses Struts wildcard
mappings and I've also demonstrated a proof of concept of how SCXML can
play in Struts Shale.

Please let me know if you have any other questions about SCXML, or how
it can be used to control a VoiceXML based conversation.

-Rahul

[1]
http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/sr
c/main/java/org/apache/commons/scxml/SCXMLDigester.java?view=markup
[2]
http://jakarta.apache.org/commons/digester/commons-digester-1.7/docs/api
/org/apache/commons/digester/NodeCreateRule.html
[3]
http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/sr
c/main/java/org/apache/commons/scxml/EventDispatcher.java?view=markup
[4] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
[5]
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorial
s/Aggregation
[6]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/scxml-dialog-test.jsp?view=markup
[7]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/config/scxml/scxml-test.xml?view=markup
[8]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/musicstore-app/README?view=markup

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


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


Mime
View raw message