Rahul,
I haven't compiled/tested, but it looks like this (below) is what is
needed in the SCXMLDigester.java? Is there any way for you to verify
and perhaps rebuild the binary - I don't want to stray too far from your
codebase. :-)
/**
* 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);
// add digestion of send element contents (these components
needed I think)
scxmlDigester.setNamespaceAware(true);
scxmlDigester.setRuleNamespaceURI(null);
scxmlRules.add(xp + XP_SND, new
NodeCreateRule(Node.DOCUMENT_FRAGMENT_NODE));
scxmlDigester.addSetNext(xp + XP_SND, "setExternalNodes",
ArrayList.class);
// end add nested digestion rules
addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
}
Your Send class has an ArrayList externalNodes which I assume you meant
for that purpose (storing nexted elements). If I'm mistaken, please let
me know. Anyhow, with this code above, perhaps you want to "clean up"
using your ...Tuple(...) method???
If you have time, the middle section code is what I think we need to add
to "digest" the contents within the <send>...</send> tags. Please let
me know if you update the SCXMLDigester and what binary to download to
test (assuming you have time to add this).
Finally, the W3C spec for <send> states that either the tag attributes
OR the nested elements are mutually exclusive. I like your
implementation and think we're better served by allowing both attributes
within the <send target="" namelist="" ...>and nested content</send>.
Your thoughts?
Resources:
-
http://rzm-hamy-wsx.rz.uni-karlsruhe.de/External/Documents-Mirrored/Java
/mirror/jakarta-commons-digester-1.4.1-src/src/test/org/apache/commons/d
igester/NodeCreateRuleTestCase.java (see testNested() and
testNamespaces() methods
- http://www-128.ibm.com/developerworks/java/library/j-lucene/
(example Digester with addSetNext to call method after closing tag???)
-
http://jakarta.apache.org/commons/digester/xref/org/apache/commons/diges
ter/Digester.html#2360 (addSetNext source)
Mike
-----Original Message-----
From: Mike Sparr - www.goomzee.com [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 06, 2005 5:44 PM
To: 'Rahul Akolkar'; 'Jakarta Commons Users List'
Subject: RE: [SCXML] Help with SCXML Send usage
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
enabler.
I would like to keep in touch and contribute where I can. If you
haven't seen yet, visit this link:
http://www.w3.org/2005/Talks/1111-maxf-delhi/
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.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 06, 2005 2:28 PM
To: Jakarta Commons Users List; [EMAIL PROTECTED]
Subject: Re: [SCXML] Help with SCXML Send usage
On 12/6/05, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> 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.
>
<snip/>
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: 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:
>
<snap/>
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 ("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);
<snip/>
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!
>
<snap/>
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/Tutorial
s/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
>
<snip/>
---------------------------------------------------------------------
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]
