Re: [SCXML] migration from old source to current - digest, exec, context handling
On 6/21/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
I tried
state id=something
datamodel
data name=foo/
/datamodel
transition event=something cond=${Conversation.request == '1'}
assign name=foo expr='bar'/
send ... Namelist=foo
soapenvbodyoperation${foo}/operation/body/env/soap
/send
/transition
/state
Both the log tag and var tags don't seem to be working. assign and
data are not capturing any data at all. Context is storing Conversation
obj which is accessible throughout.
snip/
See:
http://jakarta.apache.org/commons/scxml/guide/datamodel.html
In particular, the sections on references to data and assignments. In
a nutshell, use the name attribute of assign with var
definitions and the location attribute with data definitions.
I looked through all your tests and don't see any doc-name.xml that test
out the log or EL. In addition, your SCXMLTestHelper seems to only support
JEXL.
snap/
You may have just missed them, for example (for EL):
http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jsp/
and hello world uses log, amongst other examples:
http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/hello-world.xml
SCXMLTestHelper defaults to JEXL, but thats merely a convenience.
Suggest test of datamodel, var, assign and send. Not sure on what has
changed but temporarily will work with old codebase. :(
snip/
IMO, there has always been a (relatively easy) migration path for
early [scxml] users from the sandbox days and so I'd definitely like
to help here. However, since I'm traveling, please do me a favor and
write the smallest possible test case that does not work, and file a
ticket in JIRA (along with a brief explanation of why you think the
test should work, if that isn't obvious):
http://jakarta.apache.org/commons/scxml/issue-tracking.html
Thanks.
-Rahul
/mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] migration from old source to current - digest, exec, context handling
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
promptTo Zip Code?
/prompt
grammar src=builtin:grammar/digits?length5/grammar
noinputreprompt//noinputnomatchreprompt//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:Bodyl
it:GetDistance
xmlns:lit=http://www.tilisoft.com/ws/LocInfo/literalTypes;lit:ZipCode1/
lit:ZipCode1lit: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
Re: [SCXML] migration from old source to current - digest, exec, context handling
I tried
state id=something
datamodel
data name=foo/
/datamodel
transition event=something cond=${Conversation.request == '1'}
assign name=foo expr='bar'/
send ... Namelist=foo
soapenvbodyoperation${foo}/operation/body/env/soap
/send
/transition
/state
Both the log tag and var tags don't seem to be working. assign and
data are not capturing any data at all. Context is storing Conversation
obj which is accessible throughout.
I looked through all your tests and don't see any doc-name.xml that test
out the log or EL. In addition, your SCXMLTestHelper seems to only support
JEXL.
Suggest test of datamodel, var, assign and send. Not sure on what has
changed but temporarily will work with old codebase. :(
/mike
On 6/21/06 2:35 AM, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
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
promptTo Zip Code?
/prompt
grammar src=builtin:grammar/digits?length5/grammar
noinputreprompt//noinputnomatchreprompt//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:Bodyl
it:GetDistance
xmlns:lit=http://www.tilisoft.com/ws/LocInfo/literalTypes;lit:ZipCode1/
lit:ZipCode1lit: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':
Re: [SCXML] migration from old source to current - digest, exec, context handling
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]
Re: [SCXML] migration from old source to current - digest, exec, context handling
I will do that today and report. After the checkout, I need to edit Controller code to set the namespace handling before digestion and can then test... :) 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]
Re: [SCXML] migration from old source to current - digest, exec, context handling
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]
Re: [SCXML] migration from old source to current - digest, exec, context handling
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
Re: [SCXML] migration from old source to current - digest, exec, context handling
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:stringSmall/ResponseGroup
/Request
The above is in the sendSOAP 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 [EMAIL PROTECTED] 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}/operationaccount${account}/accountamount${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 [EMAIL PROTECTED] wrote:
On 6/18/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] 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
Re: [SCXML] migration from old source to current - digest, exec, context handling
On 6/18/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] 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.
snip/
There are subtle differences you need to be aware of, especially in
the realm of Strings and String constants (note single quotes in JEXL
for String constants etc.) -- best way to understand that is probably
to compare and constrast the EL and JEXL microwave examples (long,
possibly fragmented, URLs):
http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jsp/microwave-01.xml
vs.
http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/microwave-01.xml
Do you recall any threads that gave FunctionMapper examples?
snap/
We discussed it before, but I don't recollect any code examples. In
any case, the EL FunctionMapper interface is simple, with one method:
Method resolveFunction(String prefix, String localName);
Impl looks like:
public Method resolveFunction(String prefix, String localName) {
if (prefix != null
prefix.equals(foo)
localName.equals(bar)) {
// return Method that you want to Map to
// foo:bar(some arguments)
// should be static method of some class
}
// and so on for other functions ...
// finally, method not found?
return null;
}
You will get ready-made impls for most String manipulation functions
out of the JSTL impl in use.
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.
snip/
EL, for reasons such as:
* You are in a servlet container domain, EL is possibly all around
(and JEXL is possibly foreign)
* You have an existing system that works with EL
* String manipulation is easier with EL, IMO
-Rahul
Cheers,
Mike
snap/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] migration from old source to current - digest, exec, context handling
On 6/19/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
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.
snip/
Yes, but you shouldn't have to change the library code ;-) I think the
last time we discussed this, we decided to leave the SCXMLDigester
configurable, i.e. you should be able to parse manually (using
digester API instead of the SCXML utility methods) if you don't want
the digester to be namespace aware, say like so:
code
imports
import org.apache.commons.digester.Digester;
import org.apache.commons.scxml.PathResolver;
import org.apache.commons.scxml.io.SCXMLDigester;
import org.apache.commons.scxml.io.ModelUpdater;
import org.xml.sax.ErrorHandler;
/imports
fragment
Digester scxmlDigester = SCXMLDigester.newInstance();
// or instantiate with a PathResolver, if document contains
// references to other documents
scxmlDigester.setNamespaceAware(false);
scxmlDigester.setErrorHandler(errorHandler); // always a good idea
SCXML scxml = null;
try {
scxml = (SCXML) scxmlDigester.parse(scxmlDocumentURI);
} catch (Exception e) {
// what makes sense here?
}
if (scxml != null) {
ModelUpdater.updateSCXML(scxml);
}
// use scxml object further as before
/fragment
/code
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:stringSmall/ResponseGroup
/Request
The above is in the sendSOAP 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??
snap/
Just to confirm, this is with an ELEvaluator? (clearly won't work with JEXL).
If so, I can't see why not, if the root context contains cb.
-Rahul
If you have any ideas why this could be I'd appreciate steer.
Mike
snip/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] migration from old source to current - digest, exec, context handling
Hi Rahul,
I was unaware that after you digest you could inject params (thought it was
static) hence my meddling with your source. I will definitely try the
mentioned approach as I like that much better - agreed that was what I was
shooting for during initial conversation.
Mike
On 6/19/06 1:33 PM, Rahul Akolkar [EMAIL PROTECTED] wrote:
On 6/19/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
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.
snip/
Yes, but you shouldn't have to change the library code ;-) I think the
last time we discussed this, we decided to leave the SCXMLDigester
configurable, i.e. you should be able to parse manually (using
digester API instead of the SCXML utility methods) if you don't want
the digester to be namespace aware, say like so:
code
imports
import org.apache.commons.digester.Digester;
import org.apache.commons.scxml.PathResolver;
import org.apache.commons.scxml.io.SCXMLDigester;
import org.apache.commons.scxml.io.ModelUpdater;
import org.xml.sax.ErrorHandler;
/imports
fragment
Digester scxmlDigester = SCXMLDigester.newInstance();
// or instantiate with a PathResolver, if document contains
// references to other documents
scxmlDigester.setNamespaceAware(false);
scxmlDigester.setErrorHandler(errorHandler); // always a good idea
SCXML scxml = null;
try {
scxml = (SCXML) scxmlDigester.parse(scxmlDocumentURI);
} catch (Exception e) {
// what makes sense here?
}
if (scxml != null) {
ModelUpdater.updateSCXML(scxml);
}
// use scxml object further as before
/fragment
/code
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:stringSmall/ResponseGroup
/Request
The above is in the sendSOAP 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??
snap/
Just to confirm, this is with an ELEvaluator? (clearly won't work with JEXL).
If so, I can't see why not, if the root context contains cb.
-Rahul
If you have any ideas why this could be I'd appreciate steer.
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]
Re: [SCXML] migration from old source to current - digest, exec, context handling
:) Doh! Nevermind. I see you set the params BEFORE digestion. That is
resolved and thankfully I don't have to branch the library. :)
Regarding the EL issue, yes I stuck with EL instead of JEXL (reverted
rather). I need to look at JSTL as you recommended to handle string
functions. 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.
I did notice that when updating /lib/ with the dependent jars a few things
broke so I reverted back to prior versions [digester, beanutils, logging,
el, etc.]. Just trying to get it stable again before plugging in new
functionality and staying as close to spec as possible (hence updating
library).
I'll keep digging - if I find out what it was I can let you know. If
anything, early adopters can have a migration path to new version. :)
Best,
Mike
On 6/19/06 2:01 PM, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
Hi Rahul,
I was unaware that after you digest you could inject params (thought it was
static) hence my meddling with your source. I will definitely try the
mentioned approach as I like that much better - agreed that was what I was
shooting for during initial conversation.
Mike
On 6/19/06 1:33 PM, Rahul Akolkar [EMAIL PROTECTED] wrote:
On 6/19/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote:
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.
snip/
Yes, but you shouldn't have to change the library code ;-) I think the
last time we discussed this, we decided to leave the SCXMLDigester
configurable, i.e. you should be able to parse manually (using
digester API instead of the SCXML utility methods) if you don't want
the digester to be namespace aware, say like so:
code
imports
import org.apache.commons.digester.Digester;
import org.apache.commons.scxml.PathResolver;
import org.apache.commons.scxml.io.SCXMLDigester;
import org.apache.commons.scxml.io.ModelUpdater;
import org.xml.sax.ErrorHandler;
/imports
fragment
Digester scxmlDigester = SCXMLDigester.newInstance();
// or instantiate with a PathResolver, if document contains
// references to other documents
scxmlDigester.setNamespaceAware(false);
scxmlDigester.setErrorHandler(errorHandler); // always a good idea
SCXML scxml = null;
try {
scxml = (SCXML) scxmlDigester.parse(scxmlDocumentURI);
} catch (Exception e) {
// what makes sense here?
}
if (scxml != null) {
ModelUpdater.updateSCXML(scxml);
}
// use scxml object further as before
/fragment
/code
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:stringSmall/ResponseGroup
/Request
The above is in the sendSOAP 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??
snap/
Just to confirm, this is with an ELEvaluator? (clearly won't work with JEXL).
If so, I can't see why not, if the root context contains cb.
-Rahul
If you have any ideas why this could be I'd appreciate steer.
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]
-
To unsubscribe, e-mail: [EMAIL
Re: [SCXML] migration from old source to current - digest, exec, context handling
On 6/19/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote: :) Doh! Nevermind. I see you set the params BEFORE digestion. That is resolved and thankfully I don't have to branch the library. :) snip/ Definitely a good thing, for both of us :-) Regarding the EL issue, yes I stuck with EL instead of JEXL (reverted rather). I need to look at JSTL as you recommended to handle string functions. 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/ I haven't grasped the details of your code, so its hard for me to say what is amiss. If you can localize what bit is failing, we can possibly get further. I did notice that when updating /lib/ with the dependent jars a few things broke so I reverted back to prior versions [digester, beanutils, logging, el, etc.]. Just trying to get it stable again before plugging in new functionality and staying as close to spec as possible (hence updating library). snip/ If you remember, what updates broke what part of the library? Would be good to know. [scxml] Commons dependencies are pretty much the newest versions (though I suspect it will be possible to use many lower versions, ofcourse that can only be evaluated on a case-by-case basis -- the perils of versioned dependencies et al). I'll keep digging - if I find out what it was I can let you know. If anything, early adopters can have a migration path to new version. :) snap/ Yes, thats important. Please note that my replies will be very slow over the next three weeks, but that is because of some high amount of travel, rather than anything else. -Rahul Best, Mike snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SCXML] migration from old source to current - digest, exec, context handling
Rahul, I pulled down the latest and attempting to migrate to new scxml baseline. The following errors occurred with our implementation as they were based on earlier version. Only 5 errors referencing deprecated classes but curious the best way to digest, etc. with current? Errors are below. Also, I used the following in console and source checked out and built just fine. Check out and build latest source (from console or DOS prompt - assuming Subversion is installed): cd /some/desired/directory svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk scxml cd scxml ant - Errors based on deprecated class references: == demo_jar: [mkdir] Created dir: /Users/mike/Documents/dev/app/demoWorkspace/bin/demo [javac] Compiling 21 source files to /Users/mike/Documents/dev/app/demoWorkspace/bin/demo [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:15: cannot find symbol [javac] symbol : class SCXMLDigester [javac] location: package org.apache.commons.scxml [javac] import org.apache.commons.scxml.SCXMLDigester; [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:87: cannot find symbol [javac] symbol : method getRootContext() [javac] location: class org.apache.commons.scxml.model.SCXML [javac] getExec(cb.getClientIdentifier()).getStateMachine() [javac]^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:170: cannot find symbol [javac] symbol : variable SCXMLDigester [javac] location: class com.demo.app.scxml.AppScxmlController [javac] scxml = SCXMLDigester.digest(scxml_url, new DefaultHandler(), [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:181: cannot find symbol [javac] symbol : method addListener(com.demo.app.scxml.AppScxmlListener) [javac] location: class org.apache.commons.scxml.model.SCXML [javac] scxml.addListener(new AppScxmlListener()); [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlD ispatcher.java:141: cannot find symbol [javac] symbol : method getRootContext() [javac] location: class org.apache.commons.scxml.model.SCXML [javac] exec.getStateMachine().getRootContext(), [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 5 errors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] migration from old source to current - digest, exec, context handling
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) === 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? In addition, when I instantiated it I used the setSuperStep and setStateMachine methods before. I assume I remove those and just use #go? == 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. == 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? == Thanks, Mike On 6/18/06 2:34 PM, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] wrote: Rahul, I pulled down the latest and attempting to migrate to new scxml baseline. The following errors occurred with our implementation as they were based on earlier version. Only 5 errors referencing deprecated classes but curious the best way to digest, etc. with current? Errors are below. Also, I used the following in console and source checked out and built just fine. Check out and build latest source (from console or DOS prompt - assuming Subversion is installed): cd /some/desired/directory svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk scxml cd scxml ant - Errors based on deprecated class references: == demo_jar: [mkdir] Created dir: /Users/mike/Documents/dev/app/demoWorkspace/bin/demo [javac] Compiling 21 source files to /Users/mike/Documents/dev/app/demoWorkspace/bin/demo [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:15: cannot find symbol [javac] symbol : class SCXMLDigester [javac] location: package org.apache.commons.scxml [javac] import org.apache.commons.scxml.SCXMLDigester; [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:87: cannot find symbol [javac] symbol : method getRootContext() [javac] location: class org.apache.commons.scxml.model.SCXML [javac] getExec(cb.getClientIdentifier()).getStateMachine() [javac]^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:170: cannot find symbol [javac] symbol : variable SCXMLDigester [javac] location: class com.demo.app.scxml.AppScxmlController [javac] scxml = SCXMLDigester.digest(scxml_url, new DefaultHandler(), [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlC ontroller.java:181: cannot find symbol [javac] symbol : method addListener(com.demo.app.scxml.AppScxmlListener) [javac] location: class org.apache.commons.scxml.model.SCXML [javac] scxml.addListener(new AppScxmlListener()); [javac] ^ [javac] /Users/mike/Documents/dev/app/demoWorkspace/src/com/demo/app/scxml/AppScxmlD ispatcher.java:141: cannot find symbol [javac] symbol : method getRootContext() [javac] location: class org.apache.commons.scxml.model.SCXML [javac] exec.getStateMachine().getRootContext(), [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 5 errors - 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]
Re: [SCXML] migration from old source to current - digest, exec, context handling
On 6/18/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] 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=revrevision=371193 [2] http://svn.apache.org/viewvc?view=revrevision=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] migration from old source to current - digest, exec, context handling
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}/operationaccount${account}/accountamount${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 [EMAIL PROTECTED] wrote:
On 6/18/06, Mike Sparr - www.goomzee.com [EMAIL PROTECTED] 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=revrevision=371193
[2] http://svn.apache.org/viewvc?view=revrevision=375053
[3] http://issues.apache.org/jira/browse/SCXML-6
[4] http://jakarta.apache.org/commons/scxml/apidocs/index.html
