JavaScript scopes in JSSC

If you intend to use SCXML <script> heavily, you may want to know some JSSC implementation details.

In theory, the SCXML datamodel is supposed to be isolated from the surrounding environment. SCxml sessions have their own JavaScript scope, separate from the window that created them. In JSSC, that scope is in fact the window object of a hidden <iframe>, wherein predefined variables are shadowed so their names can be used without messing things up too much.

##Normal ECMAScript evaluation

ECMAScript expressions in attributes and <script> content are evaluated so that

• predefined variables are shadowed by the _jsscxml_predefined_ object (which is also shadowing itself and the _sc property referencing the SCxml instance)
• an uncaught Error causes an error.execution to be added to the internal queue and the entire block of executable content is terminated.

##Initial datamodel properties

When an SCxml instance is constructed with a third argument, all own properties of that argument become properties of the datamodel (and before the SCXML's own <datamodel>s are evaluated), and hold whatever value they have in the argument. It is a good way of making outside objects available to SCXML scripts. For example: new SCxml( _source_ , _anchor_ , {myLib: myLib})

##Unshadowing

If, for some reason, you want to access the outside browser environment from SCXML scripts, you may simply delete any shadowing property to make the real property visible again. The most useful property is parent, which you could use to access the main window's properties. Just make sure you and anyone else contributing to your application knows that the property can't be used for arbitrary stuff.

##Evaluation unchained

Now this is very important. There are some cases where SCXML scripts will cause some code to be evaluated outside the normal wrappers described above. These cases are:

• code delayed by setTimeout and setInterval
• callback functions of asynchronous methods like XHR
• syntactically avoiding the wrapping try and with blocks

The latter, you should simply never attempt. There is no good reason to do it.

As for asynchronous stuff, you should not call them in the SCxml's iframe unless you really, really, really know what you're doing. Instead, call the parent window's asynchronous methods, e.g. parent.setTimeout(...) or new parent.XMLHttpRequest(...)