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 ("executable" 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:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 12:02 AM To: Jakarta Commons Users List; [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
