[ 
https://issues.apache.org/jira/browse/SCXML-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-101:
--------------------------------

    Fix Version/s: 0.10

Setting fix version to v0.10 but some of this actually needs more 
clarification. Regarding the two issues you mention:

1) Its fairly easy to produce a flat datamodel actually. The API is designed so 
that many flavors of flat or heirarchical data modeling in possible with the 
Commons SCXML library. The default, as you mention, is closer to what you'd 
expect in procedural languages (equivalent to block scopes where a child has 
access to the parent's data space). The place where the decision gets made is 
in Evaluator#newContext(Context), here it is in the v0.9 Javadoc (long URL):

http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/Evaluator.html#newContext(org.apache.commons.scxml.Context)

The evaluator implementations by default return a new context, but if the same 
context is returned (which is also the root context) one will end up with a 
flat datamodel.

2) We should probably revisit the language in the spec. For large statemachines 
(with many states), the creation of all datamodels at initialization does seem 
like bloat. Moreover, when we have such state machines, usually any one single 
execution will only traverse a limited number of states. The JIT (just-in-time) 
approach Commons SCXML takes is quite effective and efficient in this regard.

 

> <datamodel> not handled as global
> ---------------------------------
>
>                 Key: SCXML-101
>                 URL: https://issues.apache.org/jira/browse/SCXML-101
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 0.9
>            Reporter: Ingmar Kliche
>             Fix For: 0.10
>
>
> The SCXML spec says: "Logically, there is a single globally visible data 
> model for the entire state machine. As an authoring convenience, however, we 
> allow <datamodel> as a child of any <state>, thus allowing parts of the data 
> model to be distributed throughout the document closer to the locations where 
> the data will be accessed. However, all instances of the <data> element are 
> created and initialized when the state machine is instantiated and may be 
> accessed from any state at any time." [1]
> There are two issues:
> 1) The current impl of commons-scxml introduced a scoping, such that <data> 
> in <datamodel> elements contained within a <state> are only visible in this 
> state and its children (due to context chain). I.e. the <datamodel> is not 
> entirely global.
> 2) Initialization of <datamodel>'s contained in a <state> (i.e. 
> non-root-datamodels) take place while entering the corresponding state for 
> the first time while creating the context (SCXMLInstance#getContext()). But 
> initialization of <data> elements has to take place at state machine 
> initialization time.
> [1] http://www.w3.org/TR/scxml/#datamodel

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to