I'm interested in the SCXML codebase, but before I could vote +1 for promotion, I'm generally thinking that the following issues need to be discussed. I apologize if this is blocking RDC.
1. SCXMLSerializer Right now the code to serialize an SCXML object is a Visitor pattern that constructs XML using a series of StringBuffers. The code to read this XML document alrady uses a straightforward set of Digester rules and the project already depends on commons-digester. *Alternative: Add a dependency to commons-betwixt, map the model package to XML. Instead of writing Digester rules for reading and constructing Strings for writing, use the betwixt mapping files as a single point of translation. The current SCXMLDigester isn't trivial by any means, but I think it would be easy to implement the external source rule. The current SCXMLDigester plays two roles, first it sets up the Digester rules and "Digests" the XML, but it also does a bit of post-processing in updateSCXML. I think the component would be well served to separate everything that has to do with serialization to/from XML into a separate package and to move some of this postProcess that happens in updateSCXML somewhere else. 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. 3. Is SCXML appropriate for Commons? Commons SCXML might not be appropriate for Jakarta Commons. See the recent discussion on general@ about componentizing different parts of Jakarta. I'm not going to fight this one because I think we're in a time of transition, but commons-scxml might ultimately benefit from producing a number of separate artifacts. scxml, scxml-faces, scxml-shale, etc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
