No luck. EL or Context are not evaluating the variables within the
transitions. At the state level, they seem to be evaluated <transition
event="name" cond="${Conversation.request == '1324'}">
...
</transition>
I see in your SCXMLExecutor#go method, which calls the #reset() method, it
states something about only adding state-level variables to the context?
See the implementation below that used to work fine with older library - now
the navigation works fine until trying to evaluate <send> contents in
Dispatcher...
====
Mike
On 6/21/06 1:07 AM, "Mike Sparr - www.goomzee.com" <[EMAIL PROTECTED]> wrote:
> False alarm, still no expressions working - el not working in digester.:
>
> Scxml code:
>
> Another transition to capture FromZip triggers event to ToZip (below) and
> then triggers getDistance. Variables are passed in namelist (pre-datamodel
> usage).
>
> <transition event="distance.toZip">
> <var name="cb" expr="${Conversation}" />
> <assign name="fromZip" expr="${cb.request}" />
> <send target="" targettype="client" event="distance.getDistance"
> namelist="cb fromZip" delay="0" hints="" sendid="0009">
> <vxml version="2.0">
> <form>
> <field name="input">
> <prompt>To Zip Code?
> </prompt>
> <grammar src="builtin:grammar/digits?length5"></grammar>
> <noinput><reprompt/></noinput><nomatch><reprompt/></nomatch>
> </field>
> <filled namelist="input">
> <submit next="http://localhost:8080/appname/Voice"; namelist="input"/>
> </filled>
> </form>
> </vxml>
> </send>
> <target next="logged_in" />
> </transition>
>
> <transition event="distance.getDistance" >
> <var name="cb" expr="${Conversation}" />
> <var name="fromZip" expr="${fromZip}" />
> <var name="soapAction"
> expr="http://www.tilisoft.com/ws/LocInfo/GetDistance"; />
> <send target="http://www.tilisoft.com/ws/LocInfo/ZipCode.asmx";
> targettype="api-soap" event="menu" namelist="cb soapAction" delay="0"
> hints="" sendid="0001">
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
> <SOAP-ENV:Body>
> <lit:GetDistance
> xmlns:lit="http://www.tilisoft.com/ws/LocInfo/literalTypes";>
> <!--Optional:-->
> <lit:ZipCode1>${fromZip}</lit:ZipCode1>
> <!--Optional:-->
> <lit:ZipCode2>${cb.request}</lit:ZipCode2>
> </lit:GetDistance>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> </send>
> <target next="logged_in" />
> </transition>
>
>
>
> ======
>
> Log show message assembled (did not embed EL strings) ** note ZipCodes
> didn't get injected into string ** :
>
> <?xml version="1.0"?><SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";><SOAP-ENV:Body><l
> it:GetDistance
> xmlns:lit="http://www.tilisoft.com/ws/LocInfo/literalTypes";><lit:ZipCode1></
> lit:ZipCode1><lit:ZipCode2></lit:ZipCode2></lit:GetDistance></SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> =======
>
> Digester code:
>
> request.append(exec.getEvaluator().eval(
> exec.getRootContext(),
> MMIUtil.getBodyText(externalNodes)));
>
> ========
>
> Adding a bunch of debug.outs to print out values of each to find out where
> it's getting lost...
>
>
> Mike
>
>
>
>
>
>
> On 6/20/06 11:36 PM, "Mike Sparr - www.goomzee.com" <[EMAIL PROTECTED]>
> wrote:
>
>> Rahul,
>>
>> Context issue resolved but only way I could get app to work was to revert to
>> my handling SCXMLDigester.digest(URL, DefaultHandler). As such, I had to
>> edit the library SCXMLDigester#digest#setNamespaceAware(false). :(
>>
>> I tried various combinations using Digester.parse but servlet always
>> returned blank screen with null printed. Logs didn't show any errors so I
>> assume that scxml was not stored or executor not started. I am going to
>> leave as-is for now. At least I have latest library and will play with
>> DataModel and add tag library string parsing.
>>
>> If you could overload the SCXMLDigester#digest(URL, ErrorHandler,
>> NamespaceAware) I'd be grateful. :) Perhaps it's best to modify the
>> newInstance() method and make that configurable instead of hard-coding
>> (true)??
>>
>> I think the issue I'm facing is that ModelUpdater cannot be instantiated in
>> my Controller. As such, I thing your SCXMLDigester can call it and that is
>> what starts the Executor and why I get 'null':
>>
>> org.apache.commons.scxml.io.ModelUpdater is not public in
>> org.apache.commons.scxml.io; cannot be accessed from outside package
>> [javac] import org.apache.commons.scxml.io.ModelUpdater;
>>
>> I wrote exact same code in my Controller as you have in the #digest(URL,
>> Handler) and it failed as wouldn't compile when I referenced ModelUpdater
>> (above). Not knowing what it really did, I commented it out to get build.
>> I ran app and just returned 'null'. I reverted to calling digest method and
>> 'hacking' library until fix (either make ModelUpdater public or preferably
>> update SCXMLDigester with new method).
>>
>> Cheers,
>>
>>
>> Mike
>>
>>
>>
>>
>> On 6/20/06 10:35 PM, "Mike Sparr - www.goomzee.com" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hey Rahul,
>>>
>>> To get the build working and change the namespace handling, I changed the
>>> reference to the filename as a String and used digester.parse(filename).
>>> Upon trying to run the application, I got error in browser stating that the
>>> build directory did not include the scxml source file??? (dir where I ran
>>> ant build).
>>>
>>> I have engine xml doc in WEB-INF/classes/engine.xml (in the classpath).
>>> Perhaps its best I put it elsewhere and should I reference a URI with that
>>> parse method? (e.g. - http://localhost:8080/appname/engine.xml)? Could you
>>> add a method to SCXMLDigester for setNamespaceAware so I can still use its
>>> #digest(java.net.URL) method?
>>>
>>> In your tests, you have the SCXMLTestHelper class. It digests the same way
>>> I used to (URL) which worked fine. I don't think you have any tests that
>>> digest with setNamespaceAware(false) declared. I propose adding that option
>>> to SCXMLDigester.
>>>
>>> public static SCXML digest(final URL url, final ErrorHandler errHandler,
>>> final List customActions) {
>>> Assert.assertNotNull(url);
>>> // SAX ErrorHandler may be null
>>> SCXML scxml = null;
>>> try {
>>> scxml = SCXMLDigester.digest(url, errHandler, customActions);
>>> } catch (Exception e) {
>>> Log log = LogFactory.getLog(SCXMLTestHelper.class);
>>> log.error(e.getMessage(), e);
>>> Assert.fail(e.getMessage());
>>> }
>>> Assert.assertNotNull(scxml);
>>> return scxml;
>>> }
>>>
>>> As soon as I get this working, I can test that context change and report.
>>>
>>> I think what I will have to do, is what you do in one of your
>>> SCXMLDigester#digest overloaded methods:
>>>
>>> public static SCXML digest(final URL scxmlURL,
>>> final ErrorHandler errHandler, final List customActions)
>>> throws IOException, SAXException, ModelException {
>>>
>>> SCXML scxml = null;
>>> Digester scxmlDigester = SCXMLDigester
>>> .newInstance(null, new URLResolver(scxmlURL),
>>> customActions);
>>> scxmlDigester.setErrorHandler(errHandler);
>>>
>>> try {
>>> scxml = (SCXML) scxmlDigester.parse(scxmlURL.toString());
>>>
>>> ... I'll try that and stick with my java.net.URL and add PathResolver. I'd
>>> rather add another overloaded method #digest(URL, ErrorHandler,
>>> CustomActions, NamespaceAware) if at all possible??? :)
>>>
>>> Cheers,
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> On 6/20/06 12:23 AM, "Rahul Akolkar" <[EMAIL PROTECTED]> wrote:
>>>
>>>> On 6/19/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote:
>>>> <snip/>
>>>>> Yes, the cb is in the context and EL works in controller but
>>>>> after updating code, it doesn't evaluate in Dispatcher?
>>>>>
>>>>> I didn't get that resolved but going to add some more debug.outs to find
>>>>> out
>>>>> what's happening with the context. As I stated before, the controller
>>>>> places the executor in a store (bridge) after instantiation and the cb in
>>>>> context stores the handle (getClientIdentifier) so it can be retrieved.
>>>>> Everything worked fine until update so there must be some minor change I'm
>>>>> not seeing.
>>>>>
>>>> <snap/>
>>>>
>>>> Mike -
>>>>
>>>> Can you try the latest code in SVN (a clean checkout)?
>>>>
>>>> While making some unrelated changes, I noticed one place where the
>>>> root context was being cleared a bit too aggressively.
>>>>
>>>> -Rahul
>>>>
>>>>
>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Mike
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
