On 1/14/06, Tim OBrien <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
