commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr - www.goomzee.com" <m...@goomzee.com>
Subject Re: [SCXML] migration from old source to current - digest, exec, context handling
Date Mon, 19 Jun 2006 06:37:26 GMT
Hi Rahul,

Everything seems to be working except for API Calls.  I changed line 455 of
SCXMLDigester to setNamespaceAware(false) instead of true and it fixed my
XSL transform issues.  Like we discussed, that was true by default but each
implementation can decide what's best.

The API Call issue is having problems with the Evaluator parsing the
externalNodes content in our Dispatcher implementation?  Implementation:

                        request.append(exec.getEvaluator().eval(
                                exec.getRootContext(),
                                MMIUtil.getBodyText(externalNodes)));

I'm not sure as I checked the SCXMLExecutor and it still has the
getRootContext() and getEvaluator() methods.  The getBodyText simply
serializes the Nodes into a single string to pass as HTTP POST.

====

Scxml source:
                        <Request>
                        <ItemId xsi:type="xsd:string">${cb.request}</ItemId>
                        <ResponseGroup
xsi:type="xsd:string">Small</ResponseGroup>
                        </Request>

The above is in the <send>SOAP ENVELOPE</send> where cb is a variable set
earlier.  It has been evaluated several times to navigate to this event.
Upon reaching our Dispatcher implementation, logs show the value (ISBN
number) was passed but when the code above evaluated the externalNodes, it
doesn't 'inject' the EL evaluated part??

====

If you have any ideas why this could be I'd appreciate steer.


Mike




On 6/18/06 8:57 PM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com> wrote:

> Hi Rahul,
> 
> Thanks for the detailed response.  I found that the build succeeds but for
> some reason, I lose the target declaration of the send tag in ctx params
> (JEXL).  Still debugging.  With the JEXLEvaluator I get null response.  By
> replacing with the original  ELEvaluator I get text strings but no
> transform.  Still trying to find out what I need to change from my
> implementation to get up-to-date with your latest and greatest.  The
> performance gains of the Context and the benefits of Datamodel are
> appealing, plus I'm appreciative for the variable scoping.  I cannot wait to
> try that out.
> 
> As you know, our use-case is a Multi-modal Interation Framework (MMI
> Framework) that allows scripting of conversational applications accessible
> by any client (web, wap, sms, voice, email, aim, msn, yim, google) and able
> to interact with a variety of back-end apis, primarily web services.  One
> desired upgrade is the ability to simplify the user experience by allowing
> multiple fields of information to be passed at once and parsed prior to
> making the web services call. (shortcuts)
> 
> For example, as our "conversation" resembles an IM or email or voice
> interaction we prompt the user with options and then accept input.  If the
> web service required multiple pieces of information (like operation,
> account_number, amount) we would have to prompt for each and collect that
> information each time.  I would like the ability for the EL engine to parse
> text strings to allow shortcuts, for example:
> 
> <operation> <account> <amount>  in one line would be tokenized and
each
> assigned <var>.  Within the <send> tags we would then have our SOAP message
> assembled and declare
> <operation>${operation}</operation><account>${account}</account><amount>${am
> ount}</amount>
> 
> Do you recall any threads that gave FunctionMapper examples?  Of course this
> could be addressed with the web service design, adding an operation that
> accepts space-delimited input, but I'd like to have the choice.
> 
> I'll continue debugging to find out how to get everything working with new
> code-base and would appreciate any steer on making the above possible.
> Which Evaluator should I use (as I'm making changes now) Commons EL or JEXL.
> 
> Cheers,
> 
> 
> Mike
> 
> 
> 
> 
> On 6/18/06 7:03 PM, "Rahul Akolkar" <rahul.akolkar@gmail.com> wrote:
> 
>> On 6/18/06, Mike Sparr - www.goomzee.com <mike@goomzee.com> wrote:
>>> Rahul,
>>> 
>>> I found the changes.
>>> 
>>> - The SCXMLDigester was moved to the .io package
>>> - #digest() signature dropped Context and Evaluator references
>>> - No longer have addListener as part of SCXML (moved to SCXMLExecutor)
>>> - No longer have getRootContext "" (moved to SCXMLExecutor)
>>> 
>> <snip/>
>> 
>> Indeed, these changes are from the Jan-Feb '06 timeframe, the primary
>> commits of importance are r371193 [1] and r375053 [2].
>> 
>> 
>>> ===
>>> 
>>> I got the build to work and will test to see if application still works.
>>> I'm curious why you moved those into the Executor?
>> <snap/>
>> 
>> SCXML-6 [3] drove those, the idea being that contexts (and listeners)
>> are state machine execution specific, and therefore, conceptually
>> attaching them to the SCXMLExecutor, rather than the in-memory model
>> of the state machine (SCXML object) makes more sense. This is, in
>> fact, related to your question from late last year, IIRC, about
>> parsing anew for each execution. Post changes above, one may parse /
>> digest once, execute many times.
>> 
>> 
>>>  In addition, when I
>>> instantiated it I used the setSuperStep and setStateMachine methods before.
>>> I assume I remove those and just use #go?
>>> 
>> <snip/>
>> 
>> Always need SCXMLExecutor#setStateMachine() before calling #go() ...
>> adding listeners, OTOH, is optional.
>> 
>> 
>>> ======
>>> 
>>> In the docs you mentioned you added a 'bridge' component at 'glue'.  My
>>> implementation leverages a custom bridge (HashMap) so I'm unsure how to
>>> retro the code to work with new base.
>>> 
>> <snap/>
>> 
>> It shouldn't be any different, the above changes do not affect the way
>> state machine execution feedback is received, or the fundamental
>> interactions the [scxml] library might have been having with user
>> code.
>> 
>> 
>>> ======
>>> 
>>> As you see, I'm replacing ELEvaluator references with JexlEvaluator.  My
>>> assumption is this will enable the functions we discussed earlier (like
>>> subStringAfter, etc.) for more text parsing capabilities that the CommonsEL
>>> package?
>>> 
>> <snip/>
>> 
>> No, none will be available out of the box.
>> 
>> On the EL side, ELEvaluators may now be instantiated with a
>> FunctionMapper (see Javadocs [4], env.jsp package), but the user needs
>> to provide a FunctionMapper for any and all EL functions needed.
>> 
>> On the JEXL side, its similar. Given the first class method
>> invocation, the user can place a "functions holder" object that
>> contains the methods needed in the root context (though the JEXL code
>> in SVN supports static method invocation).
>> 
>> -Rahul
>> 
>> [1] http://svn.apache.org/viewvc?view=rev&revision=371193
>> [2] http://svn.apache.org/viewvc?view=rev&revision=375053
>> [3] http://issues.apache.org/jira/browse/SCXML-6
>> [4] http://jakarta.apache.org/commons/scxml/apidocs/index.html
>> 
>> 
>>> ======
>>> 
>>> Thanks,
>>> 
>>> 
>>> Mike
>>> 
>> <snip/>
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message