Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 21892 invoked from network); 6 Dec 2005 21:28:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Dec 2005 21:28:07 -0000 Received: (qmail 73942 invoked by uid 500); 6 Dec 2005 21:27:59 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 73764 invoked by uid 500); 6 Dec 2005 21:27:58 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 73723 invoked by uid 99); 6 Dec 2005 21:27:58 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Dec 2005 13:27:58 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of rahul.akolkar@gmail.com designates 64.233.184.196 as permitted sender) Received: from [64.233.184.196] (HELO wproxy.gmail.com) (64.233.184.196) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Dec 2005 13:27:54 -0800 Received: by wproxy.gmail.com with SMTP id i12so606478wra for ; Tue, 06 Dec 2005 13:27:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b0sbgs2Bjw33Hz+jozIkxFBYtsxq+zAAiAnU6AumtUVGkOJSk1L2v4W2eZuHFlXQSxgR9eeIox3KcffieV5F8EI2O19G5qseCR3f0zntNtmejp+akjU6xPPyh+Td6R40AlOgVWRu6AT9BbY8Dfre7QylhuEopQNOtRgZHYjiOuc= Received: by 10.64.220.17 with SMTP id s17mr1017793qbg; Tue, 06 Dec 2005 13:27:33 -0800 (PST) Received: by 10.65.53.8 with HTTP; Tue, 6 Dec 2005 13:27:32 -0800 (PST) Message-ID: Date: Tue, 6 Dec 2005 16:27:32 -0500 From: Rahul Akolkar To: Jakarta Commons Users List , mike@goomzee.com Subject: Re: [SCXML] Help with SCXML Send usage In-Reply-To: <009c01c5fa40$b9390560$3daffea9@MSPARR> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <009c01c5fa40$b9390560$3daffea9@MSPARR> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 12/6/05, Mike Sparr - www.goomzee.com 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 . > 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
and 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: > 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 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 ("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); 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. -Rahul [1] http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutoria= ls/RDCTemplate [2] http://jakarta.apache.org/commons/sandbox/scxml/xref/index.html [3] http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons= /scxml/SCXMLDigester.html#264 [4] http://jakarta.apache.org/commons/digester/ [5] http://wiki.apache.org/jakarta-commons/Digester > Thanks, > > > Mike > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org