-
Notifications
You must be signed in to change notification settings - Fork 10
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
andwith
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(...)