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=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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
