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]
