commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
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 <tobrien@discursive.com> wrote:
<snip/>
> 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
microwave
> sample in the Working Draft, it uses a reference to a "timer" variable.  To do this with
the
> 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
this
> 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
that
> SCXML document with Digester every time I want to model a separate StopWatch.  In the
application
> 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
Context.
>
> * 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.
>
<snap/>

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.

-Rahul

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


Mime
View raw message