commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)
Date Tue, 17 Jan 2006 05:48:49 GMT
On 1/14/06, Tim OBrien <> wrote:
> 2. Decouple Execution Context from the SCXML Model
> Right now, the Context passed into the class that parses the XML and creates the SCXML
object is
> the global execution context.  You pass in a JexlContext when you are parsing the SCXML
model, it
> is assigned to all of the State objects.
> So, bear with me, assume I have a SCXML document that represents the valid states of
a stopwatch
> (ready, running, paused, stopped).  The SCXML models the watch in a way similar to the
> sample in the Working Draft, it uses a reference to a "timer" variable.  To do this with
> current implementation of SCXML, I would need to do the following twice (assuming a JexlContext):
>  a. Create a JexlContext
>  b. Populate the JexlContext with the appropriate variables
>  c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want to execute
> state machine with
>  d. Create an instance of SCXMLExecutor, pass it the SCXML from step c.
> For each watch I need to model in this application, the implementation forces me to parse
> SCXML document with Digester every time I want to model a separate StopWatch.  In the
> I'm interested in using this in, hundreds of documents in a content management system
are going to
> be modeled as individual state machines, I would hate to have to parse an SCXML file
for each
> individual document.
> * Alternative: Provide a mechanism that allows you to clone an SCXML  instance so that
you can
> create a separate SCXMLExecutor that can model the same statemachine with an isolated
> * Better Alternative: States do not "have" a context.  Take the context property off
of the State
> and change executeActionList in SCXMLSemanticsImpl to get the Context from the Executor.
> Likewise, Transitions do not have a "notificationRegistry", take that property off of
a transition
> and just have the SCXMLSemanticsImpl get the notificationRegistry from the Executor.
> I don't think this is a terribly difficult idea, and decoupling the description of the
FSM from
> the execution state, would also make it much easier to persist either one.

Most of your observations are correct. We need effective cloneability
and/or decoupling, re-parsing is a waste. If you have any ideas, do
let me know. I'll spend some time on this during the rest of the week,
primarily just starting a new thread here, will clip the email length
in the next posts.

This actually was one of the things I had in mind between sandbox
graduation and release.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message