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 02:57:56 GMT
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


Mime
View raw message