On Tue, Sep 21, 2010 at 4:35 AM, Hallvard Trætteberg <h...@idi.ntnu.no> wrote: > > > Thanks Rahul for the answer. Comments below: > >> You're correct that in this case both (or more than two) transitions >> could be selected. The selection process in v0.9 picks the first >> transition in document order (from each orthogonal region, if there >> are such regions) without inspecting the transition targets, and that >> could be changed to pick more if there are no conflicts. > > Yes, I read the code and noticed that a null target (stay) isn't considered > as a special case. > >> However, the correct solution for Commons SCXML is to port the >> SCXMLSemantics impl in use to match more closely the current algorithm >> specified in an appendix of the latest SCXML WD which always ensures >> that only one event is processed at a time (even internal events are >> queued). This change is slated for v1.0, and needs a JIRA ticket >> opened against it so it can be tracked -- you can open the ticket if >> you want, or I'll open it when I get a chance. Unless a patch becomes >> available, I don't expect to be able to update the impl for at least >> another month. > > I read the specification, but didn't find special mention of the null target > case. > They do explain why one transition overrules (preempts?) another, when they > lead > out of a region. > > However, think the issue of queueing is orthogonal to the issue of selecting > more than one target-less transition. You are right that the way I described > my case, > handling one event at time would solve the issue. But there's no guarantee > that an > event isn't used several times, so being able to select multiple target-less > transitions > is best. > <snip/>
Agreed. >> One interim solution may be to design a slightly smarter custom action >> for a wildcarded transition that initiates appropriate processing >> based on the event(s) being processed. > > My interim solution is to wrap each transition in a state, so they don't > compete. It clutters > the model, but since it is generated from a DSL, that's not a big issue. > Still, I would like > SCXML's implementation to be more "reasonable" :-). > > A final (and hopefully positive and constructive) comment: SCXML's code is > tidy and easy to read, > so implementing a custom Semantics isn't really that difficult either. What > could help, is > if some of the methods were split into parts/stages implemented by > overridable (protected) methods, > so that variations on the official semantics could be implemented in a > subclass, without much > copying of code. > <snap/> Indeed, thats a valid comment. The ability to provide custom semantics was provided to allow for any changes in executor behavior, but it wasn't anticipated to be widely used (and hence, isn't very modular). Indeed, it is probably the least used feature of the library and we don't get much feedback on it. The default semantics impl could be made more modular and easier to subclass, bearing in mind that it may have implications on backward compatibility -- though since we are at 0.x releases we can certainly make such changes if needed. If you have specific suggestions on making subclassing easier, please submit a patch for consideration through JIRA [1]. -Rahul [1] http://commons.apache.org/scxml/issue-tracking.html > Hallvard > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
